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

[CSSWG] Minutes Santa Clara F2F 2014-10-28 Part III: Text, Selections, Counter Styles

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 2 Jan 2015 09:53:53 -0500
Message-ID: <CADhPm3tF82yhKwthRpusCY9XMGzTL_NS7BoHTgyjUb6uxtwdxA@mail.gmail.com>
To: www-style@w3.org
Text
----

  - RESOLVED: Layout methods should depend on writing system in
      addition to language convention

Selections
----------

  - RESOLVED: Two-value text-overflow is line-left and line-right.

Counter Styles
--------------

  - RESOLVED: Add to Counter Styles the additional styles supported
      by 2+ browsers (per r12a's email), do not add the styles
      supported by only one browser
  - RESOLVED: Take counter styles to CR and go to the new process if
      we can
  - RESOLVED: minimum of 3 months for counter styles CR

===== FULL MINUTES BELOW ======

  Scribe: dael

Text
====

  fantasai: Let me pull up notes. The main issue was the
            justification where I'd want koji.
  fantasai: Other stuff is, as I was cleaning the handling of
            Korean, I noticed we have text saying justification
            method depends on language conventions. We need to have
            it say writing system and language convention.
  fantasai: Many languages can be written in multiple writing
            systems. The correct layout isn't only language-
            dependent.
  fantasai: Mongolian, Japanese, Turkish can be written in multiple
            writing systems. Correct layout depends primarily on the
            writing system: minor things vary by language within a
            writing system, but major things vary when you change
            systems.
  fantasai: So if anyone has comments or concerns about that let me
            know, if not I'll take a resolution to update the spec.

  murakami: For Korean and Hangul, all the text didn't have word
            spacing. and it's not sufficient to distinguish modern
            and older Hangul text. And the language attr cannot be
            used. I think the text justify property is needed for
            distinguishing modern and older style Hangul.
  fantasai: I think old style Hangul is only Hangul, correct? It
            doesn't include Latin?
  murakami: I don't think too much Hangul, but I think the word text
            was used in 1896. Before then, Hangul text did not have
            word spacing.
  fantasai: If the text does not include Latin, then inter-character
            is sufficient. If we need to worry about Latin, we need
            inter-ideographic.
  murakami: I think it's needed.
  fantasai: I think for right now it's enough of an edge case we
            should address it in the next level. In general it can
            be worked around with an inter-character value unless
            it's mixed script. In that case we'd need to look at
            reintroducing inter-ideograph
  murakami: Inter-character isn't good for old Hangul. The Latin
            letters may be included in all Hangul text.

  TabAtkins: Is there much old Hangul on the web?
  murakami: I don't know very much, but some examples I posted on
            the mailing list.
  murakami: Not I. Someone else posted.
  fantasai: I think someone said they were wrong.
  TabAtkins: The KL examples were pretty wrong.

  fantasai: I don't have a strong opinion, but I think jdaggett does.
            I think we should take justification up when he calls
            later today.
  fantasai: I think we should come back to this and resolve on
            effects being writing system and language dependent.
  fantasai: Any concerns with that issue?

  RESOLVED: Layout method should depend on writing system in
            addition to language convention

  fantasai: The rest needs to be in the afternoon.
  fantasai: I think andreyr had a selection issue?

Selections
==========

  andreyr: We discussed this in Sophia, but fantasai put together
           the spec. The grammar and spelling squiggly lines, we
           wanted to control that color.
  andreyr: We asked to add it to the spec. Any objections or
           opinions?
  florian: It was mentioned that there are security concerns, but it
           can be handled as long as we're careful.
  TabAtkins: You're limited to only color property things that don't
             affect layout.
  fantasai: Add ::spelling-error and ::grammar-error and have it
            follow restrictions in layout model of ::selection and
            add additional security verbiage.

  <liam> [ is the squiggly line already a text-decoration value? ]
  <astearns> liam: yes. wavy:
             http://www.w3.org/TR/css-text-decor-3/#text-decoration-style-property
  <SimonSapin> liam, yes, 'wavy'
               http://dev.w3.org/csswg/css-text-decor/#propdef-text-decoration-style
  <liam> [ thanks, although does this let you colour it differently
         from the text?? ]
  <SimonSapin> liam, text-decoration-color

  plinss: Do we want a distinct pseudo-element or a functional one?
  plinss: I'm just curious.
  andreyr: I don't have an opinion.
  fantasai: I don't have much of one. We already have ::selection.
  plinss: I'm thinking of other uses like annotations. I'm wondering
          if it's an extensibility point, or do we add more names?
  fantasai: I think we're adding names either way. Spelling-error and
            grammar-error need to be built-in.

  plinss: Is it the full scope or a limited scope? [use functional
          notation like :dir()] It's something to consider.
  fantasai: Full pseudo-element space for now. If we find a need to
            extract it we have time.
  fantasai: There was discussion of having custom selections. That
            would need to be encapsulated in a functional notation.
            For these in the browser they won't be custom. Keeping
            them out of the custom scope is a good idea.
  fantasai: We won't be mixing custom and pseudo, which is a good
            idea.

  plinss: Adding to what?
  TabAtkins: pseudo-elements
  plinss: Wasn't pseudo-elements abandoned for a while?
  TabAtkins: Didn't we just revive it?
  fantasai: Yes. the plan is work in the meeting, do more testing,
            then post to www-style, ask for reviews, and then ask
            for FPWD.

  SimonSapin: What are the security issues?
  fantasai: :visited exposes history, this exposes your dictionary.
  TabAtkins: It's a fingerprinting link.
  plinss: We need to care about those. Also, in things like OSX your
          address book gets added to your dictionary, so it's
          definitely a security thing.
  plinss: Even if you want to say fingerprinting is a lost cause,
          you don't want to open the surface error. You don't want
          to say I don't care about fingerprinting.
  TabAtkins: But once I can be fingerprinted, more doesn't hurt.
  plinss: It's a different set of values. And there are folks
          working on fingerprinting.

CSS3 UI: text-overflow
======================

  florian: It was pointed out yesterday we made a resolution on
           ellipses with two values we said start/end instead of
           left/right. Given that a fairly reasonable usage is
           arrows, we may want absolute directions.
  fantasai: That's why the spec currently has left/right.
  florian: The other argument is there are some things that do flip.
  fantasai: We have line-left and line-right. It should be physical
            and Mozilla implemented that.
  florian: It's that or let the author pick what he needs.
  plinss: Are there use cases in both ways?
  fantasai: I've seen ellipsis and arrow, I haven't seen start and
            end differentiated.
  florian: If you go with parentheses, they mirror, but you probably
           don't want to. The reasonable use cases don't need that.
           We could later have a syntax to let you say start/end.
  florian: We also pointed out that it was inconsistent, but when
           you have a value it applying to end makes sense.
  florian: So it stays inconsistent. It's not clean but sounds
           practical.

  plinss: In my mind, I'm thinking when it shows up it's logical,
          but which one we choose is physical.
  fantasai: It depends on scroll position. Initial scroll state is
            logical.
  TabAtkins: It depends on if it's overflowing this end.
  plinss: In the single value case you're not specifying the end,
          it's just a value with where ever there's overflow.
  florian: I think you specify end. I'm not sure you should, but
           that's what it says.
  plinss: So you explicitly don't get an ellipsis on the other side
          if you only have one value. You never get one on the start
          end.
  florian: If there is one value it only applies to end line edge.
  fantasai: Whatever is there is probably right.
  plinss: Is that what we want?
  fantasai: Given that the one value has a lot of use, we can't
            change a whole lot. There's silliness already, like you
            have to spec overflow not visible. That's the behavior
            we're stuck with.
  florian: So do we agree to replace yesterday's resolution with
           line-left and line-right?

  RESOLVED: Replace yesterday's resolution for start/end with
            line-left and line-right

Counter Styles
==============

  fantasai: It's in LC. Any open issues? If not, let's go to CR?
  TabAtkins: One issue was about a handful of styles that browsers
             have implemented but weren't in the draft since we cut
             it down. I want to add the ones with high
             interoperability.
  TabAtkins: About 20 styles are implemented since they are
             dependable for authors.
  TabAtkins: The ones that aren't clear is the Tamil style, which is
             only Firefox and this list:
  <TabAtkins> afar, oromo, sidama, tigre

  florian: For the 20 you talked about, you said reasonable, is that
           2 or more implementations?
  TabAtkins: 2 or more.
  TabAtkins: The list above is supported by the browsers with roots
             in webkit.
  TabAtkins: My opinion is to not put them and recommend that
             they're removed for consistency. It's still in the
             original document. So, yea or nay on that. Keep the
             ones that are implemented by more than one browser.
  TabAtkins: I'll ask for removal with bugs.

  plinss: Is that what we want?
  TabAtkins: Yeah. If you do the author definition, you don't need
             the one to be in Firefox.

  plinss: Other opinions?
  Bert: Can you repeat the ones you keep?
  TabAtkins: It's long. If you find the list in the archives there's
             a list from Richard Ishida of the additional values
             supported by Firefox and webkit derived.
  TabAtkins: All the values are in the spec right now.
  TabAtkins: The ones that are only supported in one browser are in
             the minutes above.
  florian: Are we confident they're right?
  TabAtkins: Richard has been testing and he's confident.

  florian: We pushed them out because we aren't sure. Hopefully they
           match what speakers would expect. If that's true I'm
           happy with the spec.
  TabAtkins: It's just listing them. They can be fixed in the future.
  florian: One reason we're pushing in this direction is to avoid
           time discussing languages we don't understand.
  plinss: But it's not all browsers.
  TabAtkins: Everybody but IE which is pretty close.
  TabAtkins: If no one objects we can keep the list of 2+ browser
             supported languages and not have the one browser
             supported.

  RESOLVED: Add to Counter Styles the additional styles supported by
            2+ browsers (per r12a's email), do not add the styles
            supported by only one browser.

  TabAtkins: That's the only e-mail for counter styles since the LC
             announcement.
  TabAtkins: So given that I've made the change in the ED can we go
             to CR?
  Bert: Go for it!
  TabAtkins: This has to be old process CR.
  fantasai: I think you should be able to go into the new.
  florian: We said it wasn't clear if you can do it with this.
  TabAtkins: I think we can just do it.
  plinss: I think the document says if you're in LC you cannot
          switch to the new process.
  fantasai: We've fulfilled the old process requirements.
  plinss: Let's resolve to take counter styles to CR and go to the
          new process if we can.
  TabAtkins: So objections to publishing under some form of CR?

  RESOLVED: Take counter styles to CR and go to the new process if
            we can.

  plinss: I propose we break until 2pm.
  [lunch break until 2pm]

  Bert: Is everyone here, shall we start?
  Bert: I guess for Fonts we need jdaggett. Can someone ping him to
        call?
  TabAtkins: While we wait, Richard pointed out we didn't choose a
             minimum time for CR for counter styles.
  Bert: What time? Do we do 6 or 3 months?
  TabAtkins: 3 months?
  ChrisL: You can always take longer.

  RESOLVED: 3 months for counter styles CR
Received on Friday, 2 January 2015 14:54:20 UTC

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