- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 3 Nov 2016 05:38:53 -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.
=========================================
overflow:hidden SHOULD or MUST not be scrollable
------------------------------------------------
- RESOLVED: Change this (overflow:hidden not scrolling) from
SHOULD to MUST.
- RESOLVED: For the quoted [Overflow spec] text we are changing
SHOULD to MUST and MAY to MUST. (Text quoted here:
https://github.com/w3c/csswg-drafts/issues/666)
Hyphenation Priority
--------------------
- RESOLVED: No change on this issue
(https://github.com/w3c/csswg-drafts/issues/618).
Insufficient normative reference to UAX14 for the ID line breaking
class
-------------------------------------------------------------------
- RESOLVED: No change to the spec because it already requires
customary line breaking rules.
Add shorthands for alignment property
-------------------------------------
- RESOLVED: Use place-items place-self place-content shorthands.
- The group will revisit the use of slashes once people have had
more time to review and think through the implications.
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Nov/0005.html
Present:
Rachel Andrew (IRC Only)
Tab Atkins
Bert Bos
Tantek Çelik
Elika Etemad
Brad Kemper
Ian Kilpatrick
Chris Lilley
Myles Maxfield
Anton Prowse
Alan Stearns
Greg Whtiworth
Steve Zilles
Regrets:
David Baron
Dave Cramer
Daniel Glazman
Tony Graham
Dael Jackson
Brian Kardell
Vlad Levantovsky
Peter Linss
Jen Simmons
Scribe: tantek
astearns: We're postponing item 1 initial letter since Dave Cramer
is not on the call.
astearns: Any extra items for the agenda?
astearns: Let's try #2
Florian: I'd rather have fantasai for 2. [css-text-3] hyphenation
priority https://github.com/w3c/csswg-drafts/issues/618
Florian: can we do #4?
overflow:hidden SHOULD or MUST not be scrollable
------------------------------------------------
Florian: I was surprised to learn that overflow spec had
overflow:hidden SHOULD
Florian: I ran into it by reviewing a test depending on
overflow:hidden not being scrollable to expose a bug on
Safari on iOS.
Florian: I believe everyone thought it should be a MUST.
astearns: smfr replied saying that iOS behavior not intentional
and he is ok making it a MUST.
astearns: I'm grateful for that, and hope it gets added to the
github issue.
astearns: Anyone else have concern making it a MUST?
bradk: I'm concerned that existing pages might be dependent on the
scroll wheel scrolling it.
Florian: I don't think the scrollwheel scrolls it.
bradk: I'm not a 100% sure either but seems like there might be
some browsers that might.
<gregwhitworth> do we have a testcase for the scenario that iOS
works in?
Florian: So yes we have a test case.
Florian: It's linked from the github.
myles: I agree with smfr that this is just a bug in webkit.
iank: I think it makes sense to switch to MUST.
Bert: I try to remember why we wrote it this way.
Bert: I think it was just a case of writing English instead of
spec text.
Bert: I think we intended MUST
astearns: PROPOSED change this (overflow:hidden not scrolling)
from SHOULD to MUST
astearns: anyone object?
RESOLVED: change this (overflow:hidden not scrolling) from SHOULD
to MUST
myles: There are two spec places though
myles: ... and ... - are those both going to get changed to MUST?
Florian: I was talking about the first one.
Florian: Maybe scrolling progammatically also sounds like
attempting to write English not spec text.
iank: When I was writing JS apps there's quite a few that depend
on scrolling things programmatically.
astearns: So we're changing MAY to MUST in both cases?
Florian: I haven't considered that initially, but I agree with
that as well. Same problem, English instead of spec text.
<bradk> Must allow programmatic scrolling
astearns: Backing up, is there any concern about changing both
cases?
tantek: Looks like bradk is bringing up a distinction.
Florian: I can phrase this as a non-awkward way.
Florian: If I can avoid double negatives that would be good
astearns: For the quoted [Overflow spec] text we are changing SHOULD
to MUST and MAY to MUST. Is that correct?
Florian: mm-hmm
astearns: Any objections?
RESOLVED: For the quoted [Overflow spec] text we are changing SHOULD
to MUST and MAY to MUST. Everything gets changed to MUST.
Hyphenation Priority
--------------------
astearns: ok, hyphenation.
<Florian> https://github.com/w3c/csswg-drafts/issues/618
Florian: Hyphenation priority.
Florian: For hyphenation there is a requirement that if there is
an actual hyphen in the word, that hyphen should take
priority over anything in the dictionary.
Florian: I was looking on the spec for an opinion
Florian: and the spec does have this for soft hyphens
Florian: but not for "real" hyphens or hard hyphens.
Florian: My initial call was extending the language that applies
to soft hyphens to also apply to hard hyphens.
Florian: It was pointed out that that language was very strict and
completely disallows breaking at the dictionary break
points.
Florian: A smarter hyphenation engine may want to prioritize the
hyphen over the dictionary break points, but still allow
the other one.
Florian: Should we say anything about this? and which way should
we go?
Florian: If we are in an engine that has a notion of prioritized
hyphenation points then do explicit hyphens then
dictionary,
Florian: but if we are not in such an engine, then we apply the
same language about soft hyphen to hard hyphen.
fantasai: I would prefer not to say anything about soft hyphens.
fantasai: Especially ... there are cases where that is not the
best place to break.
fantasai: The reason a soft hyphen disables automatic hyphenation
is because automatic hyphenation would do the wrong thing
fantasai: and thus you want to suppress the automatic hyphenation.
myles: Everything fantasai said is correct.
Florian: Yes I agree as well.
fantasai: I think prioritization of hyphenation is something we
should not be getting into.
Florian: Point taken. ok. we can close this.
fantasai: Resolution no change.
astearns: Any objection?
RESOLVED: no change on this issue (618)
Insufficient normative reference to UAX14 for the ID line breaking
class
------------------------------------------------------------------
astearns: Let's go on to UAX14.
Florian: There are no rules in CSS3 Text for ... line breaking ...
rule.
Florian: There are places that say such and such must behave as ID
class
Florian: But it does not seem to be required.
ChrisL: It sounds like ...
fantasai: We normatively reference UAX14 that deal with line
breaking chars.
fantasai: The rest of UAX14 is informatively reference and that's
intentional
fantasai: because UAX14 pairs table is not going to get you the
best result.
fantasai: We are saying here is some information about
line-breaking, please incorporate
fantasai: but here is some additional information to consider.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2014Aug/0321.html
ChrisL: Sounds like two separate things. UAX14 as a baseline, and
not, do whatever you want.
Florian: Pick a subset of what UAX14 says about the ID class
Florian: because there is one part that is completely reasonable.
Florian: Between chars of the ID class, and between chars of the
ID class and regular stuff
Florian: then there is a wrapping opportunity
Florian: but if between ID class and a word joiner then don't
(break).
Florian: What do you do around punctuation, small kana
Florian: I don't think we should define that.
Florian: but we can point to the line-break property which defines
some.
Florian: But between Kanji and a letter ...
fantasai: ... do xyz width
fantasai: We have wording that says do the appropriate thing, e.g.
in the word-break property.
fantasai: I don't want to prescribe any kind of algorithm beyond
you must honor all the line-breaking control points
fantasai: because then what about this set of characters vs these
other characters.
fantasai: Do we normatively require ... tailored ...? this is not
our job.
fantasai: Going through Unicode and determining all the line
breaking chars is UAX14's job and it's not great.
fantasai: it's not our job. bunch of ... and ... and ... ? why
subset?
fantasai: Do we want to make the requirement only to punctuation,
some subset, ... ? I don't see the point in calling this
out.
fantasai: It should be fairly obvious that if you are not putting
breaks between two Kanji characters then you are doing
something wrong.
Florian: Can I depend on that for a test?
fantasai: Yes.
ChrisL: Is it a baseline or is it do whatever you want?
Florian: I was trying to get a minimal sensible subset of UAX14
that everyone can agree on, and I agree your concern that
without any normative requirement it makes me nervous as
well.
fantasai: ... words break according to their customary rules as
described above.
fantasai: If you're doing something that is obviously not
customary then it is obviously not customary and
obviously wrong per spec
fantasai: and that is the case for break in between two kanji.
myles: Also expressing support for fantasai.
Florian: If we agree the spec is sufficient for testing breaks
between Kanji
Florian: then I am ok.
fantasai: The text I quoted is enough, the word customary is a
normative requirement.
<fantasai> https://drafts.csswg.org/css-text-3/#valdef-word-break-normal
astearns: There are tests that rely on customary western line
breaking as well.
astearns: There are tests I've written that look at line breaks,
and they try to make it the most obvious of what I think
the line breaking should be, but I'm not sure I can find
an assertion in the spec that proves it
astearns: and I'm ok with that ambiguity in creating tests
Florian: I'm ok with if we are ok with having this ambiguous but
normative way of doing tests, then I am ok with it.
Florian: I don't want this to be a reason to reject a test.
fantasai: We also allow testing may.
astearns: Maybe that is the threshold for putting explicit
normative text in the spec.
astearns: That if you have a test that is reasonable for your
interpretation of customary, and someone disagrees, then
we need to add text to the spec.
astearns: So the resolution is ...
Florian: I would prefer long worded resolution.
<fantasai> RESOLVED: Spec already requires sane line-breaking
rules.
<fantasai> (so no change)
<fantasai> astearns: s/sane/customary/
astearns: Any objection to resolution of no change to the spec
because it already requires customary line breaking
rules?
astearns: Alright that is resolved
<Florian> proposed resolution: no change, the spec uses
intentionally fuzzy wording but does have normative
requirement about following customary line breaking rules
RESOLVED: No change to the spec because it already requires
customary line breaking rules.
Add shorthands for alignment properties
---------------------------------------
astearns: Alignment shorthands
astearns: ... and slash separator.
fantasai: I don't know if [missed]
fantasai: My main concern with the slash is that we don't have one
... now, so we end up with two that are almost the same
but not.
TabAtkins: The scroll snap align is very simple
TabAtkins: this is not
TabAtkins: so we cannot do it without a slash.
TabAtkins: Without it would be largely worthless.
TabAtkins: We could allow you to only specify one (and another
with space), which is possible but also weird.
fantasai: Do we want scroll snap to also allow slash?
fantasai: What happens if we extend scroll snap?
TabAtkins: Reasonable to me.
fantasai: It's confusing that they're not consistent.
fantasai: It would be nice if they were consistent.
fantasai: Otherwise authors would have to remember ...
fantasai: We also have background positioning without a slash.
fantasai: I'm not really happy the fact that you can't just be
like here is how you do centering.
fantasai: We don't have any consistency here.
TabAtkins: Sure, if you wanted to do it with a single value, you
specify center and you're done.
TabAtkins: I get your concern otherwise.
TabAtkins: And it's not really you want to do start in one axis
and center, for scroll snap you say start center, and
for ... you say start / center.
TabAtkins: I'm fine with adding slash to scroll snap.
fantasai: We also have the consistency issue with
background-position.
fantasai: They all take the same subset of keywords.
fantasai: Alignment keyword, followed by another
fantasai: We can't do three of them because background-position
does not take /
TabAtkins: And we can't do zero of them because that restricts
drastically what we can specify in the alignment
properties.
fantasai: But in the alignment properties the only thing we not
allow is a distribution value in addition to a fallback.
fantasai: We could positionally restrict the safe and unsafe
keywords.
fantasai: The only problem is a distribution keyword followed by
an alignment keyword.
fantasai: Only problem is ... if you only have one item
fantasai: you wouldn't be able to do that in a shorthand [missed].
TabAtkins: ... restrictions on what value types are allowed are
subtle and hard to remember
TabAtkins: sometimes you can cleave it well
TabAtkins: but this time it is grammatical.
TabAtkins: Slash is annoying to remember, but at least it's just a
quirk that you realize for a particular property
TabAtkins: rather than a subset of syntax, much higher cognitive
load
TabAtkins: because if you do try to write it and get confused.
TabAtkins: The cognitive load of slash vs no slash is less bad
than any syntax restrictions we could put in.
fantasai: I think that point is correct but I'd like more feedback
before we resolve.
astearns: I think I'm fine, I prefer putting the slash in, so that
we can express everything we want in the shorthand.
astearns: I think we can have that as a general rule, if a
shorthand could become ambiguous, then we could add a
slash.
astearns: We could add a slash to background shorthand at some
point.
fantasai: That would make background shorthand problematic to
distinguish ... from ...
astearns: It sounds like we can resolve today to use place as the
alignment shorthand.
<gregwhitworth> we can bikeshed later once we see the spec
astearns: Does anyone object to using place as the alignment
shorthand?
astearns: We are going to resolve where and which shorthands have
slash
astearns: We are going to get back to this
astearns: Resolution is that we are going to use place-* as ... or
what is the actual?
astearns: What is the actual shorthand?
TabAtkins: place-items place-self place-content
astearns: We resolve to use those three place-* shorthands
astearns: and we will revisit where to use slashes in shorthands.
RESOLVED: Use place-items place-self place-content shorthands.
astearns: Anything else?
fantasai: Hanging punctuation issue?
Florian: I thought you were supposed to come with some detailed
wording that we would look at?
fantasai: So the wording in IRC was not sufficiently clear?
astearns: I was waiting for wording in the issue itself.
astearns: If that's it for today
astearns: we can end a few minutes early.
astearns: Thank you everyone for calling in and thank you tantek
for minuting.
<astearns> the initial letter topic was postponed to next week
when we hope dauwhe can attend
Received on Thursday, 3 November 2016 09:39:57 UTC