- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 2 Jan 2015 09:57:41 -0500
- To: www-style@w3.org
Snap Points
-----------
- The group reviewed progress on Snap Points. Discussed some
concerns over:
- behavior at the start/end of a scroller
- travelling past multiple snap points during scroll
gesture/animation
- graceful degradation on smaller-than-expected screen sizes
- RESOLVED: Publish FPWD of snap points
Text
----
- Discussed options for specifying justification behavior for
untagged content.
- RESOLVED: No examples of justification algorithm for
text-justify: auto
- RESOLVED: Link to a wiki or NOTE collating information about
language-specific justification conventions.
===== FULL MINUTES BELOW ======
Scribe: dael
Snap Points
===========
<smfr> http://dev.w3.org/csswg/css-snappoints/
MaRakow: I updated the spec, roc had some responses, I wanted to
see if there was concern about my edits.
MaRakow: If not I'd like a FPWD.
MaRakow: For anyone that haven't looked at the edits, I've removed
most of the requests for new functionality that doesn't
exist in a browser.
MaRakow: I need feedback for name of snap-coordinate and
snap-destination.
MaRakow: Those are the main topics.
MaRakow: I wanted feedback.
End-of-element snap point
-------------------------
smfr: I haven't caught up, but were there responses to hober's
e-mails?
MaRakow: I don't think I have anything about that. I'd say no
because our implementation doesn't include implicit steps.
smfr: So there's content you can't scroll to without snap points?
MaRakow: Which is intentional.
smfr: We have things where at the end you want the last element on
the right edge and the scroll element is stuck. I'm not sure
if that use case works.
MaRakow: Could merge element and interval snap lists. You can
merge an interval and element snap points.
smfr: We'd prefer repeat with an extra place go to the end.
User interaction with snap points
---------------------------------
smfr: Two other areas that are under-specified. One area was how
do you transition between scrolling gesture and animating to
a snap point.
smfr: That can get weird if you have to go back.
MaRakow: That was intentionally under-spec'ed. The dynamic point
is on a snap point. That's partly for when you don't have
an animation and also to allow freedom.
smfr: So like if you're going fast and want to skip the nearest
point.
smfr: I don't know if we need that specified.
smfr: Also, exactly how proximity works.
MaRakow: Again somewhat one purpose. I think the heuristics are
best for UA. It's going to be soft and should break
anything. I think it's best unspecified.
smfr: Maybe errors that you want to avoid you can leave a note in
spec.
smfr: Final thing. If the user isn't scrolling but the snap points
change, do you adjust?
MaRakow: I added that. Mandatory behavior is that you must update
to land on a snap point, optional for proximity.
Varying screen sizes
--------------------
fantasai: One thing I want to make sure is handled well is varying
screen sizes. I think some of your examples would work
if it's smaller than the screen, but not if bigger.
fantasai: If you have a mandatory snap point in the middle, but
you're on a smaller screen than the picture, you can
never see the whole thing.
MaRakow: I think that's where it would be inappropriate to mandate
scroll offset.
fantasai: You want to mandate it lands on each picture.
MaRakow: You want the user to scroll to the end and not snap.
fantasai: People design for one screen size and don't think about
smaller. Whatever we're designing here if they don't
think about it they should still get something
appropriate.
MaRakow: My take is that you still don't want to use mandatory.
fantasai: The person designed stopping on each picture. They
didn't think about my small screen. We enabled something
that degrades badly. Degrading well is better.
MaRakow: I don't know if there's a solution to that.
MaRakow: It's a part of responsive design, that is you need to be
aware of a small screen.
fantasai: I'll review the draft, but in general we should consider
that.
Summary
-------
MaRakow: The notes I took were adding implicit snap points on
start/end of the scroller, maybe as a repeat function
option,
MaRakow: Specing the ability to travel past multiple snap points
with inertial,
MaRakow: And adding something about screen size.
MaRakow: So can we do FPWD?
RESOLVED: Publish FPWD of snap points
plinss: Anything else on that?
Text: Justification
===================
fantasai: Okay.
fantasai: Let's start with justification.
fantasai: I'd like jdaggett's comments.
fantasai: Text-justify: auto when the content is untagged. How do
we deal with conflicting Korean and Japanese?
jdaggett: Better language tags.
fantasai: And for the default?
jdaggett: So you don't know what the language is?
fantasai: Yes.
jdaggett: It's not ideal because Japanese content in an English
browser won't show the right way, but it's justification.
I'm not sure how critical it'll be.
fantasai: In general we try and not use locale.
jdaggett: It's not optimal, but it's what implementors do today.
fantasai: So if I have Mozilla with untagged Japanese in a
Japanese location it uses CJK spacing?
jdaggett: That would depend. I know Japanese font selection we do
sniffing of locale
fantasai: Not for justification, I don't think. Given that we
don't do it we shouldn't start.
jdaggett: There's a lot of things, ie line breaking, where it's
untagged and we use locale.
jdaggett: I'm not sure. Auto is a catch all. What needs to be
defined?
fantasai: We were asked for an example of a justification
algorithm that shows off here's what you could do if you
need justification and have no additional information.
fantasai: We want that same for most languages.
fantasai: Korean wants to expand spaces, but not between Han.
Japanese wants no space expanding, but wants at Han.
jdaggett: Is that the case for auto? Are you talking justify:
auto?
fantasai: Text-justify: auto
fantasai: If they're using distribute they get spacing everywhere.
If they specify a language tag they get the right thing.
The case with this problem is it's untagged and auto.
Some browsers don't do any spacing in Japanese. Others
are like let's justify between Han and Hanna and that
looks weird for Korean because hopefully no one will
notice since they don't use a lot of Han.
fantasai: Those are the two things implemented. Another option is
two levels of priority. Expand at spaces if they get too
wide and then expand between CJ and K.
fantasai: Those are the three options. I can put them all in the
spec, or just one of them. I'd like to close on this
today so we can go forward.
stevez: jdaggett, sniffing makes sense. If you have Hangul you
should do your Hangul thing. That would get us away from a
suboptimal solution.
fantasai: I don't want to sniff locale. That gets web designers to
think their webpage looks awesome.
jdaggett: This is sort of a none-issue. We can infer from the
script.
fantasai: We haven't been doing that. If implementors want to do
sniffing, I can put that in the spec.
stevez: None of the three answers are good. They're all bad.
There's a possibility of being good in all cases if you
sniff.
florian: How much do you sniff? It's not picking the wrong one,
but it's being unstable.
stevez: These are documents without a language tag. If you want it
to work, language tag. I understand you're saying people
won't language tag if it looks good.
jdaggett: I don't understand why a normative algorithm is
important.
florian: But you'd get where my website looks fine and then you
switch and it breaks.
fantasai: We have a non-normative algorithm that we're supposed to
put in. Normatively we only have a handful of
requirements.
jdaggett: I'd suggest that if the language isn't set, see if it
can be inferred from the script. Just put that as a
suggestion.
fantasai: It's up to implementors. The feedback I was given
earlier were we don't want to sniff. If people feel
differently now that it's 10 years later, I can do it.
But that needs to be consensus.
stevez: Last discussion is there is no algorithm that works well
for both Korean and Japanese without a language tag. We
can pick one that doesn't work for a language and we end
up in a bad situation where we picked a language, or we
can do the simple sniffing thing.
stevez: In the cases we care about, you'll see soon what language.
If it's all Kanji, you can do a good job.
florian: Sniffing gets you unstable. You see Chinese and get more
content and you see diversity. Nothing is great so we
have to accept some suckage.
fantasai: I want to hear from dbaron because he's wanted more
details on auto.
dbaron: The kind of details I wanted auto to have are the kind
that avoid saying "hey browser implementors, you do the
research on the right behavior for all these languages."
dbaron: I think if...If you know the right behavior for language
tagged and if you want to say the behavior for untagged
isn't defined, that's better than not defining the correct
behavior. You're defining where is the thing you should do
for each language.
fantasai: We can't put that normatively in this doc.
stevez: You have what's normative for tagged.
fantasai: We don't.
stevez: That was the wiki?
fantasai: Yeah. What's normative is for auto justification.
[cites spec]
fantasai: There's some discussion about if Chinese and Japanese,
Kana Kanji and Hangul should be the same within a line
or different and we've had some feedback from Japan that
they want differently.
fantasai: So we need a "what works"
fantasai: We can add a link to a document to what we think is
right for this small handful of scripts and good luck
for the rest.
r12a: You have Japanese, we're working on Chinese and Mongolian.
We can get more. I wouldn't have thought you needed to spec
all Japanese layout in a CSS spec.
dbaron: Or refer to it. I don't think it's reasonable to expect
original research on hundreds of languages. The
requirements should be in or linked to.
fantasai: I think we don't have requirements for lots of languages.
dbaron: So it's not in this level of the spec.
fantasai: It should all be in a note.
stevez: That was the purpose of the wiki, to allow contribution
without us vetting.
fantasai: If you're happy for us to have what we know about this
handful of languages, if that's sufficient, I'm happy to
put that in the spec instead of an example of a default.
dbaron: What I wasn't okay with that is that I felt what used to
be there was saying you had to do original research. I'm
fine with that.
stevez: Do we have a location we can point to?
fantasai: I think we can do that through i18n WG.
stevez: Yours, r12a, doesn't specify that. I think it points to JL
rec. The generic site.
r12a: That points to JL rec.
<r12a> https://www.w3.org/International/wiki/Improving_typography_on_the_Web_and_in_eBooks
<r12a> https://www.w3.org/International/wiki/Improving_typography_on_the_Web_and_in_eBooks#Alignment_and_justification
r12a: We can talk about it.
stevez: Maybe as a joint project. So I'd object to saying they're
required or normative, they're information that would
allow people to do a reasonable job. The question is how
do you do interoperability testing.
stevez: Some people would have practitioners that would allow them
to do better. The JL are one set, but not the only set.
That's why Adobe tabled a bunch of the things like spacing
and line breaking
fantasai: Yeah. We have some normative requirements so what we can
test are what I read out. We can test if it's just if
one option is there.
fantasai: You can test that that first character ended up on this
end, that's the most we can do.
fantasai: If that works for people I'm happy to not put in a
suggested algorithm.
florian: If we end up not defining that's fine. We should be
careful about opening the sniffing door. People who
worked on encodings found content sniffing was not a good
idea. The situation is different.
stevez: It is different because rules are tied to script. The
amount of sniffing to hit 90% is not much. You may get
errors and you say please language tag it. I would propose
that you add that browsers may sniff the script to suggest
which rules to use.
r12a: The other possibility is that we allow it to be broken if
you don't specify the language on purpose.
florian: The problem is legacy content. For new things that's a
great idea, but there's legacy out there.
dbaron: That's what we did for hyphenation. We said auto doesn't
work without a language specified.
fantasai: Mozilla just does spacing.
dbaron: It's conditional if it's language Chinese or Japanese
which comes from local, tag, or inferred from content. If
our best guess language when we have to come up with a
language comes to Japanese or Chinese, we use different
rules.
fantasai: There was explicit language, character set, and locale.
dbaron: The http header falls in there.
<jdaggett> plus accept-lang http header
stevez: Maybe the right thing to say is UA implementation may use
what information it has about the language in determining
the spacing rules.
fantasai: The one that that will be tricky if you'll get wildly
different results depending on what the UA thought the
language was.
<jdaggett> wildly different?!? cmon...
stevez: Then I agree with florian that we're trying to encourage
using the language tag.
fantasai: But if it's user generated or only works on the one page
they checked, some will fail, but you're like oh it
looks great here.
fantasai: I'd like to not do content or locale sniffing. Those are
most likely to cause accidental breakage.
florian: What would be the correct way to deal with you're writing
a web mail client in Japanese and get a plain text Korean
message?
fantasai: You don't justify plain text e-mails.
r12a: It's only confusable with Japanese if using Hanga characters.
Korean is only confusable with the Hanga character and
they're few and embedded into Hangul in that example. It's
more difficult with titles in Japanese, but that's a limited
amount of text.
stevez: And those aren't typically not justified.
fantasai: They might be.
plinss: We're about out of time.
plinss: Are we finding common ground?
fantasai: I think we don't need an example algorithm in the spec.
dbaron: It would be nice to not lose your research.
stevez: We should create the wiki with your information.
bert: And it would be nice to turn that into a note.
stevez: It's informative.
bert: But a date on it.
murakami: I have a question. I think most people will be happy if
language is not specified. Hangul is inter-word
justification, and others (Japanese and Chinese roots)
are inter-character
fantasai: It's awkward for Korean with Hana in it because you have
spaces in the middle of the word. So imagine if you had
spacing around each side of Kanji.
murakami: The language attr should be specified. If it's not
specified the optimized justification cannot be expected.
florian: We're allowing, but not requiring.
fantasai: Question is do we put it in the spec. I can put
algorithm examples in the spec.
fantasai: They're all acceptable options. I can put them into spec
if it's useful.
florian: To be clear, I don't think we have consensus on what
you're not allowed to do. It's not obvious that we're
agreeing.
fantasai: I'm not sure of compatibility impact.
dbaron: I suspect that location would be bad for Japanese content.
fantasai: Does Microsoft sniff?
ArronEi: I don't believe so.
Rossen: I don't believe so. I have to check.
fantasai: Let's do some testing. If IE does not justify Japanese
when it's untagged using the locale to do that, we might
say to do that.
fantasai: We can come back in a few weeks after all the edits have
been made.
fantasai: One complication with backwards compatibility is some
browsers honor text-justify: interideograph. We dropped
it but documents that spec that will expect to be
justified. It will be justified in Microsoft because
they support it and Mozilla because the sniffing.
hiroshi2: A character, sniffing for locale. In an extreme case,
the text exists, how do you sniff that and what
justification algorithm should be applied?
fantasai: So we were suggesting sniffing locale, so I have
American flag, so it says because my computer I will
justify like English. You don't look on text, but rely
on operating system.
florian: That's another option.
stevez: If you can't guess what it is by looking at character you
go back to the default set of rules because no matter what
it won't look good. From where I'm sitting the goal would
be do a large portion of the existing archive in a way
that won't surprise the users of that archive.
dbaron: Why are we specifying this stuff?
florian: Are there things we can agree to not use, it's what I
talked about.
jcraig: I'm not sure I agree to use the language tag. The
likelihood a template uses lang=en is pretty high.
fantasai: Justification isn't disruptive if you don't do it
correctly.
jcraig: So it's fine for justification, not determining accurate
language.
florian: It's hard to get anything better.
fantasai: It also incentivizes doing it correctly.
r12a: And people tag correctly a lot more. That's not the case
anymore. But the other argument is true where if it's not
working, you figure out why and change the language tag.
zcorpan: In HTML there's a rule to determine the language and it
first looks at language tag. Then there's a step that
looks at content language. Step 3 is HTTP header.
dbaron: It feels like we're expanding this discussion instead of
solving our problem.
stevez: So we drop trying to resolve allowing or forbidding and
just go with the text dbaron can live with and so can
fantasai. That resolves for now and there's work to do,
but not on the doc itself.
<zcorpan_> https://html.spec.whatwg.org/multipage/dom.html#language
r12a: I'd like to see tests to see what happens on the browsers.
I'd like to help create those tests.
fantasai: We can talk about those during i18n.
fantasai: So either don't put an example of a justification
algorithm or put in multiple examples?
jdaggett: I think if you put in one, it has to be real world and
not made up.
fantasai: I'm talking algorithm, not text.
fantasai: One we can put in is the one murakami-san mentioned.
stevez: I'm okay with multiple, not with one.
plinss: Okay with none?
stevez: I am on the basis I'd like to see us establish a site
where we can put the information in. It's informative
information.
fantasai: Is there a preference between none or multiple?
florian: As long as the multiple are somewhere, I don't care where.
<jdaggett> The examples should simply highlight good choices :)
<jdaggett> Single or multiple is not as important as them being
good...
dbaron: Either option comes with a link to the wiki?
fantasai: Yes.
dbaron: I'm fine with either.
stevez: None and a wiki link.
RESOLVED: No examples of justification algorithm for text-justify:
auto, link to a wiki or note describing language
specific conventions
<Bert> (Fantasai's white board text: 1) Lang tag; 2) Content-
Language HTTP header; 3) System/OS locale; 4) Content
sniffing; 5) Charset)
* fantasai notes that list should probably be unordered, maybe
using letters
plinss: Is that it?
plinss: Thursday there's a joint meeting with digipub in the
morning and SVG in the afternoon. There's also i18n in the
morning.
fantasai: Friday morning.
dbaron: Can someone put times on the wiki? The top and bottom of
the wiki disagree.
dbaron: Come Thursday I'm just going to look at the wiki.
plinss: We'll fix it.
plinss: We're adjourned.
[end of meeting]
Received on Friday, 2 January 2015 14:58:09 UTC