- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 29 Aug 2012 19:28:24 -0700
- 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)
Lists
-----
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
----------------------------------
http://wiki.csswg.org/topics/custom-ident-case-sensitivity
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
handled
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,
brackets.
fantasai: I don't see any use case where forced upright is better than
upright.
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
inferior.
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
Unicode.
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
upright
* 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. :-)
Lists
-----
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
----------------------------------
http://wiki.csswg.org/topics/custom-ident-case-sensitivity
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
document
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