W3C home > Mailing lists > Public > www-style@w3.org > August 2012

[CSSWG] Minutes and Resolutions 2012-08-15 Wed PM II: Writing Modes, Lists and Counter Styles, Case-sensitivity and Normalization

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 29 Aug 2012 19:28:24 -0700
Message-ID: <503ECFC8.9050101@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Writing Modes

   - Koji summarized the results of the August UTC meeting
   - RESOLVED: text-orientation:upright is a forced upright; it always means upright
               (because UTR50 does not define SVO anymore)


   Tab Atkins summarized what's in the Lists module, and asked for feedback:
     - marker positioning / layout rules
     - counter-set property, to handle <li value="5">
     - ::marker pseudo-element
     - marker-attachment property to handle bidi use cases: controls whether
       list marker "belongs" to item or to list, wrt directional formatting
     - inline list item display type

Case-sensitivity and Normalization

   RESOLVED: user-idents in CSS are case-insensitive, insensitivity of a
             type TBD, but where the type of case comparison allows for
             atomization and hashing via a single up-front conversion

Counter Styles

   RESOLVED: Move @counter-style rule and symbols() function to the counter
             styles spec. Retain in that spec the 2.0, 2.1 and the six way
             cjk ideographic split (which is marked at-risk). Move rest of
             counter styles to registry on W3C wiki.

====== Full minutes below ======

Writing Modes

   koji: In the end I would like one working group resolution, so would
         like to start from some background.
   koji: UTR50 started last August
   koji: At that point, there was a problem that UTR50 defines it scope
         to capture major us in Japanese, and there was probably a little
         different from what fantasai wanted for CSS3 Writing Modes
   koji: So after UTR50 draft 1 was done, there was a lot of feedback
   koji: But rather than each codepoint issue, of upright vs. sideways,
         but what is scope and goal of UTR50 and scope/goal of Writing Modes
   koji: The editor, Eric, set scope to Japanese
   koji: Most feedback I saw was scope should be global rather than Japanese
   koji: Other feedback like multi-language / math expressions should be
   koji: Some people want that consistency by ignoring some legacy usage
   koji: Some people want better typography than what's used today
   koji: Some issues resolved by discussion, but in the end, everyone wants
         different scope for UTR50 and discussion was stuck, and that's
         what I saw before the UTC meeting

   jdaggett: I don't think that's a fair representation because the basis
             of UTR50 was to make the default orientation a character property
   jdaggett: To not be a combination of other properties and font information
   jdaggett: The original draft of Writing Modes had that as the defining
             factor of orientation
   jdaggett: The goal of UTR50 was to give us a default distinction, that
             at least set Latin sideways, and kanji upright
   jdaggett: beyond that, I don't think it's as important
   koji: Everyone agrees with that
   koji: Issues is about symbols
   jdaggett: Key point is that this thing have consistency
   jdaggett: Specifics of whether one symbols is upright/sideways is much
             less important
   jdaggett: Just trying to set a set of reasonable default
   jdaggett: If you're talking about math expressions in vertical text,
             you're off in the weeds
   jdaggett: What has come out of UTC and the mail you sent around, this
             is the scope
   jdaggett: That is much more confined scope, I'm fine with that
   koji: The UTC resolved to tighten the scope
   koji: Now UTR50 scope is Japanese and then East Asian
   koji: And it's goal is interchangeability rather than better typography
   koji: And to capture major use

   florian: So they won't address non-EA things?
   koji: I misunderstood at first point, but scope they mean priority
   fantasai: Scope is all of Unicode
   fantasai: Figure it out for all of Unicode -- the question is when
             different usage has conflicting requirements, then usage
             in East Asia wins
   koji: For that, usage in East Asia wins, and Japanese wins over that
   koji: For some scripts, Unicode defines its scope to being able to
         write about such scripts, but not to write its native scripts
   Florian: ...
   jdaggett: and that's precisely why we shouldn't bikeshed on this
   koji: Basic idea is goal of UTR50 is to interchange
   koji: For various specific applications, encouraged to tailor
   koji: So UTR50 resolved to go back or tighten the scope
   koji: means if we follow UTR50, CSS Writing Modes scope would match
         that of UTR50
   Florian: Question is They have changed the way they define everything,
            are we ok with that.
   jdaggett: As long as there's not an uproar, then it's okay

Scribe: dbaron
   fantasai: UTC's scope document (UTC member confidential) seemed
             reasonable to me
   fantasai: though one point I wanted clarified
   jdaggett: I think writing mode should just say that ... is defined
             by this property over here in Unicode.
   fantasai: I think we just need them to publish a draft that has known
             errors fixed.
   jdaggett: Koji, I'm upset that you were going to UTC meeting as
             representative of this group without informing us what was
             going on before it.
   koji: I apologize for that.
   koji: I prefer to use UTR50 as is, and I want to make sure everyone
         is ok with that.
   jdaggett: I think we're all fine.

   koji: UTC resolved not to do SVO for the first version.
   koji: writing mode has text-orientation: upright.  Discussion about
         whether upright is forced or smart.
   koji: e.g., parentheses being upright
   koji: UTC had resolved to add SVO to solve that
   jdaggett: I think we should make text-orientation: upright be upright always
   jdaggett: authors who want sideways parentheses should use sideways
             (or mixed)
   koji: Could defer smart upright or define our own properties
   fantasai: or refer to existing draft tables.
   florian: it's an option, but we shouldn't pick it
   jdaggett: It's only an illusion that this is smart.  It only goes so far.
             In many situations it will not look right.
   florian: This kind of table can only be maintained by Unicode.
   Steve: I'd propose we either drop upright or leave it as forced upright
          as Koji suggested.
   Steve: And we have the option, later, if a table for smart upright is
          later defined that we think is worth adopting, we have the option
          of adding a value to use that.
   Florian: I think that's fair.
   fantasai: My original intention with text-orientation that all values
             would be usable at a span level or at a paragraph level.
   fantasai: If upright becomes forced-upright then forced upright is only
             usable on a particular span, because it breaks on hyphens,
   fantasai: I don't see any use case where forced upright is better than
   Steve: Do you want to take upright out?
   Steve: We don't have a definition of what smart upright would do.
   jdaggett: We need upright in some situations.
   jdaggett: Need to have it for making Latin upright.
   Florian: I think we're in agreement.
   fantasai: I'm not happy with upright being a forced upright, but I'm
             not going to override the WG.
   fantasai: I don't think there's a use in having a value that is always
   fantasai: We could use the data that are already there.
   Florian: I think having smart upright would be nice, but I wouldn't do
            it before Unicode defines and maintains what it means.
   jdaggett: I think smart-upright is an illusion.
   koji: UTC had some discussion on this, and they may add the value of
         ??? in the future.
   Bert: Can you explain difference between smart and forced?
   fantasai draws "(some-text)" in both forced and smart upright
   jdaggett: With a regular font this isn't going to work, because regular
             fonts don't have vertical metrics.
   fantasai: If you have a font that has vertical metrics, or you're using
             capital letters...
   fantasai: People want to do this on book spines and things -- to get
             this effect without smart upright, you need to put spans
             around ( - and )
   jdaggett: For the set of use cases here I think that's acceptable.
   alan: esp. if you have to modify the spans individually for the lack
         of font metrics
   fantasai: If you don't have vertical metrics you might as well use ...
   Florian: I understand that smart upright is valuable, and I think we
            can pursue it in the next level based on what's going on in
   Peter: We're still calling the value 'upright'?
   jdaggett: If you have smart upright, then you have no way of forcing
             character to upright
   fantasai: You could use tate-chu-yoku.
   RESOLVED: text-orientation:upright is a forced upright; it always means
   * fantasai is sad we are resolving to add a feature that has no use case
   koji: Excel does forced upright up until 2007; switched to smart upright
         in 2007.  Been doing vertical writing since 1995.

   koji: Last one is HO property is being removed from UTR50 draft 7.
   jdaggett: Mongolian and Phags-Pa are vertical-only languages, but for
             convenience when they are discussed in English text they are
             often rotated into the horizontal
   jdaggett: The way the fonts are designed -- typically designed rotated
             90 degrees.
   jdaggett: The HO property was to call out set of scripts that have this
             behavior -- scripts that are vertical only but rotated left
             when displayed horizontally
   Glenn: Goes back to history of Mongolian
   [discussion of history of scripts]
   jdaggett: It was never really a very important property, because it
             just said whether the script was Mongolian or Phags-Pa.
   Koji: Some points have different orientation of glyphs from the Unicode
         code chart.
   Koji: So to make visually correct orientation you have to render
         differently from UTR50.
   Koji: Because UTR50 reflects against code charts, and code charts and
         fonts don't match.
   Koji: ...
   jdaggett: Summarizing:  the handling of Phags-Pa and Mongolian is
             different from other scripts in the way you deal with
             orientations, and you can leave it to implementations to
             figure that out.
   Steve: Using the horizontal metrics in vertical settings
   jdaggett: Spec can write a simple sentence saying that the way fonts
             are designed for Mongolian and Phags-Pa are unique, and
             implementations need to deal with that separately.
   fantasai: Problem is that the Unicode code charts have it upright
             as though in vertical text, but fonts have it sideways
             assuming reference is horizontal text.
   Steve: Just the way people historically made the fonts.

   Bert: schedule?
   jdaggett: I think the draft needs cleanup first.
   fantasai: Also need to wait for UTR50 to publish an update.
   Steve: As long as it's in something equivalent to last call or one
          step away from...
   jdaggett:  First we need a WD that just says [...]
   jdaggett: The ED right now points at a fictitious property.
   Bert: What schedule do we expect?  LC soon?
   jdaggett: Depends on edits Koji makes in Unicode.
   koji: ... incorporates changes that have been discussed.  Draft 7 will.
         Expect to publish next UTC (November).
   koji: UTC has public review period after the draft.  If people agree
         with it, could go quickly.
   jdaggett: First step is to get a WD that says ...

   fantasai: Other thing we were blocked on was an objection from Glenn
             on the naming of the logical directions.
   Glenn: before/after vs. head/foot
   Steve: Glenn made one objection, Murakami-san made one, I'm unhappy
          (but only unhappy)
   jdaggett: Can we put an issue in the spec labeling this as an objection?
   GLenn: Don't want to block this; I'm in the unhappy category.
   Glenn: Some concern about cultural notion of head and foot.
   jdaggett: Why can't we mark this as an issue?
   jdaggett: shouldn't block this as a WD
   [agreement, it seems]
   [desire to resolve before LC]
   Steve: Are people willing to reconsider this or should we go away and
          give up?
   Florian: I'd prefer not to reconsider.
   Peter: I'd prefer not to discuss discussing it right now.
   Peter: We'll rename it before we go to last call. :-)


   ScribeNick: fantasai
   TabAtkins: There are two issues to talk about
   TabAtkins: This has been sitting in WD because nobody has reviewed
              the draft yet
   TabAtkins: Would like to advance the spec
   TabAtkins: Otherwise I'll request LC

   TabAtkins: In simplest case, marker positions are same
   TabAtkins: Outside that, all implementations have different ideas of
              how markers are positioned
   TabAtkins: spec is similar to what IE does, because that was sanest
   Rossen: 3 years ago looked at it
   Rossen: We spent a ton of time looking at list markers and looked at
           all the different implementations
   Rossen: As soon as you have anything other than simplest possible
           text with marker inside, all hell broke loose
   dbaron: There's a section called marker positioning, but nowhere near
           long enough to cover all this
   TabAtkins: Split across marker position and marker attachment
   TabAtkins: Actual definition in Ch 7
   TabAtkins: 7.1 defines behavior in terms of terms, and what that means..
              then defined in ... right there
   <dbaron> http://dev.w3.org/csswg/css3-lists/#positioning-markers
   TabAtkins: If it's incomplete, please give me feedback. Correct me on
              anything that's wrong.

   TabAtkins: Counter handling. Everybody is pretty sane on this
   TabAtkins: Tried to tighten up definitions in the spec
   TabAtkins: Added the counter-set property, equivalent to counter-reset,
              except doesn't create a new scope
   TabAtkins: This is required if you want to implement HTML's value
              attribute in terms of CSS
   TabAtkins: same as counter-increment, just sets to explicit value instead

   TabAtkins discusses some weird case

   TabAtkins: I defined the ::marker pseudo-element
   TabAtkins: So you can style it, e.g. color the marker
   TabAtkins: Can be done right now with hacks and markup tweaks, rather
              annoying to do

   TabAtkins: marker-attachment property, was put in at request of bidi
              requirements groups
   TabAtkins: To address the problem of list markers appearing on the
              wrong side
   dbaron: I think this is a bad name
   TabAtkins explains the use case
   dbaron: We had a really long discussion about this at a TPAC
   dbaron: Given that there's a whole bunch of issues with whether the
           marker follows text-align stuff, or whether it moves around
           floats, 'marker-attachment' sounds like it addresses those
           issues, and it doesn't
   dbaron: maybe 'marker-side' or 'marker-direction'
   * hober marker-direction-follows: [parent | list-item]
   Rossen: If it's an arrow, if it points to the left or the right? :)
   plinss asks about direction of marker contents

   TabAtkins: Last thing is inline list items
   dbaron: Does it support list-style-position: outside
   TabAtkins: Hm, probably should
   TabAtkins: Ok, those were changes that need review
   TabAtkins: Let's start with one jdaggett is pacing about

Case-sensitivity and Normalization

   TabAtkins: Which is the question of user-defined identifiers
   TabAtkins: Do we preserve the case of user-defined idents?
   TabAtkins: ASCII case-fold?
   TabAtkins: ..
   jdaggett: we should design a simple system
   jdaggett: this is not very important
   jdaggett: CSS is otherwise case-insensitive
   TabAtkins: Interesting thing here is that @counter-style lets you
              redefine idents, including case-insensitive ones in CSS2.1
   jdaggett: users expect it to be case-insensitive
   TabAtkins: So proposal is to make them case-insensitive, figure out
              which kind it is
   jdaggett: Not always the best ways, but define something simple
   jdaggett: for where handled within itself
   Florian: Seems reasonable, but what do you do on the OM side of things?
   Florian: Does the OM output the saem case as input or lowercase or what?
   TabAtkins: Just do whatever OM does for idents
   fantasai: What idents do depends on whether it's a predefined keyword
             or not
   jdaggett: There are user idents in @font-feature rules
   Florian: From an author point of view, jdaggett's proposal is best.
   Florian: Question is if we will get this right on implementation side
   dbaron: What is jdaggett proposing?
   fantasai: Unicode lowercasing
   dbaron: In some cases where there are user-defined idents, we want a
           mechanism for fast comparison
   dbaron: such as atomization
   dbaron: if there isn't a function that you can get a unique thing
           that you can compare, then we have a problem
   dbaron: some unicode case comparisons that don't give you that
   <smfr> animation keyframes use user idents too, which are exposed to
          JS via animation events
   jdaggett: You might be thinking of full case mapping
   jdaggett: Unicode has simple case mapping and full case mapping
   jdaggett: full case mapping doesn't preserve length of a string,
             e.g. eszet will become double capital S
   jdaggett: There's also a simple set that preserves length of string
   fantasai raises issue of lowercasing, uppercasing, case-folding
   ACTION jdaggett: propose case-comparison proposal
   <trackbot> Created ACTION-507
   TabAtkins: Should we resolve on ASCII-case-insensitivity?
   jdaggett: Uncertain about that
   TabAtkins: It's in the platform, HTML has it in a number of places too
   Bert: Agree with jdaggett that it's a weird thing
   TabAkins: I'm concerned about going back to case-sensitive
   plinss: So we're proposing to make idents case-insensitive in a form TBD
   dbaron: I'd also like to resolve that the form will support atomization
   dbaron: There has to be some conversion you can do once, such that you
           can do atomization
   fantasai: I think that's true for all of the casing optimizations.
   fantasai: You just can't do round-tripping.

   plinss: What about Unicode normalization?
   plinss: These identifiers are going to cross document boundaries,
           and cross into script. entirely possible that multiple style
           sheets applying to one page are generated by different people
           with different editors with different normalizations
   jdaggett: then they will not match
   dbaron: If we want to fix that, then we want to normalize the whole
           sheet as parse time
   TabAtkins: I don't think you can avoid perf problems without doing that.
   dbaron: You have to do it in so many different places.
   dbaron: Unless you can test this for everything
   fantasai: I think if we had a normalization form that worked for content,
             we could normalize the entire web platform on parse, and it'd
             be fine. But we don't have that.
   fantasai: So I don't think we can do normalization until we have a
             normalization form that works.
   plinss: That's valid feedback to i18n
   plinss: This issue keeps coming up
   RESOLVED: user-idents in CSS are case-insensitive, insensitivity of a
             type TBD, but where the type of case comparison allows for
             atomization and hashing via a single up-front conversion
<dbaron> The definition of Caseless Matching (Case Folding) in Unicode 6.0
          section 5.18 actually seems like it would be ok.

Counter Styles
Scribe: Bert

   fantasai: Previous discussion was to have counter styles in a different
   fantasai: Proposal is to put @counter-style with them
   Florian: Point of splitting was to not put the counter styles list on the REC track
   scribe: Bert
   fantasai: Definitions of all counter styles in 2.1 make a good module.
   fantasai: Finished and complete, after case-sensitivity issues.
   fantasai: All the rest deals with a lot of things, not near LC
   fantasai: It is holding up counter style
   fantasai: So we might as well give it is own module
   jdaggett: As bare minimum you need to address OM
   TabAtkins: Takes 5 mins to define.
   TabAtkins: As soon as I have a checkout of the spec.

   fantasai: Splitting counter-style
   florian: jdaggett has an opinion, but not as strong as whether or not
            to define long list of counter styles normatively.
   florian:  We should on defining that long list.
   florian:  I vote for not.
   glenn: define whats in 2.1 and that's it.
   fantasai: Don't want to limit ot 2.1
   fantasai: The criteria for 2.1 where basically what bert and howcome
             knew about.
   tantek: Will fantasai draw up criteria?
   dbaron: We should have definitions for the 2.0 ones, some of which
           were dropped from 2.1. Everyone implements them.
   glenn: Want to focus on 2.1, want to see a proposal.
   fantasai: Want to consider how hard it is for author to come with a style.
   fantasai: If it is hard, we should prefedine
   fantasai: Khmer might be easy for an author.
   fantasai: CJK is not.
   glenn: mapping between numbers and symbols and then author can work it out.
   fantasai: that's what were talking about
   jdaggett: Multiple ways of doing it.
   <dbaron> http://www.w3.org/TR/2008/REC-CSS2-20080411/generate.html#propdef-list-style-type
   <dbaron> has a bunch that are not in 2.1
   TabAtkins: Should not define a common resource. W3C would not host it.
   glenn: rathole to define what is significant or not, based on community size, e.g
   jdaggett: We don't know what the quality is of the definitions we have.
   jdaggett: Should be a community effort.
   plinss: You say (1) we cannot define it, (2) it is a quality issue.
   jdaggett: We cannot judge the quality. Who can judge the Khmer numbering here?
   glenn: I was there and I would not accept a proposal unless it came from
          the government there.
   florian: We should draw a line somewhere.
   tantek: jdaggett is asking for community. Community provides examples,
           test cases, etc. We can check them.
   jdaggett: We cannot check them.
   plinss: You are arguing there is no public review.
   florian: Toss it out to specialized group.
   SteveZ: Why doesn't the wikipedia solution work here? Put it out,
   SteveZ: Leave the community to get it right.
   SteveZ: *We* are not going to get it right.
   TabAtkins: OK

   fantasai: I'd like a counter styles module
   fantasai: That defines 2.0 and 2.1 styles.
   fantasai: And has informative appendix with the other currently in the draft.
   some people: no
   plinss: [missed]
   tantek: We have a wiki. Propose it there.
   tantek: If the community steps up, that's great. If not, too bad.
   koji: I agree wiki is good place to develop for a community. But once
         developed, how to put it in browsers?
   florian: You don't.
   florian: Authors copy it it to their own style sheets.
   SteveZ: Knowing what we know, we would have created a registry.
   dbaron: here is the set in 2.0, I think all implemented in browsers.
   dbaron: One value got split in current draft, because of multiple interpretations.
   dbaron: CJK ideographic.
   dbaron: Split into 6 values.
   fantasai: Complication with that one is that an author is not going to
             come up with that on his own.
   fantasai: Those should be in the required set of built-ins.
   dbaron: I think the required set should be the 2.0/2.1 set plus these 6.
   plinss: 2.0 is not the justification, it is just our source.
   tantek: What is already implemented is the justification.
   dbaron: It is sane and not a big addition.
   glenn: 2.1 list is enough for me.
   glenn: Everything else, incl 2.0, in a registry.
   dbaron: Don't kick out if it is implemented cross-browser.
   [discussion about what FF supports]
   florian: I can live with dbaron proposal. Not further than that.
   TabAtkins: Everything else goes into registry on wiki.
   sylvaing: test cases?
   dbaron: I think I submitted some. May have been removed since.
   sylvaing: If we don't get 2 implementations, we can remove.
   sylvaing: Strat with that, everything goes to wiki.
   TabAtkins: Testing is easy, generate a 1000 numbers.
   RESOLVED: Move @counter-style rule and symbols() function to the counter
             styles spec. Retain in that spec the 2.0, 2.1 and the six way
             cjk ideographic split. Move rest of counter styles to registry
             on W3C wiki.
   [discussion about origin of six-way split of cjk ideographic]
   florian: Mark 6-way split at risk?
   dbaron: Agreed.
   RESOLVED: {cont'd) and mark 6-way split at risk.
   glenn: I object to 6-way split. At risk is OK.
Received on Thursday, 30 August 2012 02:28:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:20 UTC