W3C home > Mailing lists > Public > www-style@w3.org > January 2015

[CSSWG] Minutes Santa Clara F2F 2014-10-28 Part VI: Snap Points, Text

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 2 Jan 2015 09:57:41 -0500
Message-ID: <CADhPm3tf-kSV54nSPR7=X-cf1XggZKQEXAR-xZdGTY0dRwMUBw@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:27 UTC