- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 13 Jul 2011 17:48:03 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Discussed default orientation of characters in vertical text
- Discussed logistics for Seattle F2F. Sylvain needs people to
register so he can plan.
- Draft CSSWG charter sent to AC:
http://www.w3.org/2010/09/CSSWG/charter.html
- RESOLVED: publish the CSS device adaptation spec FPWD
- ACTION to everyone to review CSS3 Speech
http://dev.w3.org/csswg/css3-speech/
and to collect comments on HTML5 LC
http://www.w3.org/TR/html5/
====== Full minutes below ======
Present:
César Acebal
David Baron
Bert Bos
Kimberly Blessing
John Daggett
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Arno Gourdol
Koji Ishii
John Jansen
Brad Kemper
Vincent Hardy
Chris Lilley
Peter Linss
Divya Manian
Edward O'Connor
Florian Rivoal
David Singer
Daniel Weck
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2011/07/13-css-irc
ScribeNick: vhardy
Administrative
--------------
glazou: New agenda topics?
fantasai: discussion about priorities and schedule for things in writing-modes
glazou: anything else?
<glazou> http://lists.w3.org/Archives/Public/www-style/2011Jul/0004.html
Writing Modes
-------------
glazou: writing modes, following from last week
glazou: I missed the last minutes of last week.
jdaggett: this is Fantasai's proposal. My proposal is different.
jdaggett: I do not see the need to compare the bidi algo.
<jdaggett> Figure 7: http://dev.w3.org/csswg/css3-writing-modes/#vertical-intro
jdaggett: for the text orientation, you need a way to distiguish for
different unicode point, which are going to rotate and the ones
that are going to remain upright.
jdaggett: if you look at figure 7 in the writing mode spec (link above).
jdaggett: this is the problem that text orientation is trying to address.
You have content that is rendered in different directions
depending on context.
jdaggett: 2011 is rendered upright but also rotated right.
jdaggett: If you have normal punctuation ascii characters for example, it
is not clear what direction they should have in all cases.
jdaggett: For emoticon, for example, the orientation may be different
depending on context (e.g., in english text or in japanese text).
jdaggett: My proposal was that for ambiguous characters, they would take
the orientation of the surrounding text.
florianr: it seems that what your propose is close to what fantasai is
proposing.
jdaggett: yes, but I do not see the need to bring in BiDi to resolve this
simpler problem.
florian: if you want to drop the introduction, that is fine.
jdaggett: BiDi has nesting behaviors.
fantasai: in some cases, the context is ambiguous, and BiDi has already
solutions for resolving ambiguous contexts.
fantasai: I could rewrite without using the BiDi reference but use the
same algorithm.
ACTION fantasai: rewrite proposal to not reference bidi because it's confusing
<trackbot> Created ACTION-338
<dsinger_> It seems that the same ambiguities arise don't they?
jdaggett: starting the explanation by details of the BiDi algorithm is obtuse.
fantasai: Is the action item satisfactory?
glazou: the issue is about the algorithm, not the word BiDi
<dsinger_> So John thinks some other algorithm applies??
fantasai: I thought you wanted the same behavior. I do not understand what
you want.
szilles: I sent a message last night which suggested that using the script
TR instead of the BiDi TR would make more sense. Simpler, covers
a number of the cases that jdaggett wanted to cover.
szilles: It is a simpler description. It is not algorithmic unfortunately.
There are problems with matching code.
szilles: The second thing I suggested (less sure about this one, but
suggested to me by Eric): since there are a number of characters
that cover the common cases (punctuations and symbols) that come
with a particular full width code. If you want the unrotated one,
you would use the full width code. I am less certain about this one.
szilles: Eric was suggesting that we should have simple rules that did not
try to be clever if we did not need to be.
jdaggett: we need to decide to address or not address: what is the use of
full width code points in this mode. You suggest to use it as a
way to guarantee that the characters are upright.
jdaggett: this may create problems with search in browsers.
fantasai: this is broken in browsers. They should use NFK decomposition.
jdaggett: if you have NASA, there are actually two different code points
for each letter: one is the ascii version and one is the full
width version. In vertical text, the natural orientation of
ascii characters is rotated right. For full width, they remain
upright in vertical text.
jdaggett: we are talking about presentational attributes. They have nothing
to do with content. We are talking about changing the code points
to fit the presentation.
jdaggett: I am not sure if it is indirectly, but in JLRec they are going
away from using the full width code point.
szilles: I do not disagree. I wanted to bring it up, because it provides a
simple consistent rule.
szilles: I think this was also the rule in the original Microsoft
implementation.
jdaggett: do we want to perpetuate this.
szilles: what is the mechanism for a person to control things if the rules
do not do what we want?
jdagette: we need a default rule. Every code point has a natural orientation.
Then, how do you control for characters that can go both ways.
These two things are different. The spec does not have a way to
define the default.
florianr: the current spec., even though using BiDi, has a mechanism for
defining the default orientation.
jdagette: The appendix has definitions, that if you take normatively, would
give you a definition. jdaggett says there is no normative
definition.
jdagett: I do not think these should be in appendices. Appendix C, if you
are just writing a classification scheme is ok. If you are
explaining the classification, it should be in the body of the
text and it should be normative.
jdagett: we need a better default.
<dsinger> 1) vertical writing is not an exclusively web/html/css problem,
and we shouldn't be defining how to do it; that's a Unicode
problem.
<dsinger> 2) the existence of two code points for 'N', 'A', 'S' is not our
problem either
<dsinger> I'm still unclear whether the problem is that (a) Elika's algorithm
is wrong or too complex, and we need to refer to a different one
(b) the write-up is too complex or confusing or (c) the write-up
should not mention Bidi.
florianr: I agree we need something and it should be normative. If we take
fantasai's mail, removing the BiDi reference, and moving text to
the body of the text. Is that something we agree on?
szilles: no, I do not agree with the algorithm. Also, there is disagreement
on whether the code point should be used to determine orientation.
* glazou allocates no more than 3 extra minutes to this topic
<glazou> we shift at :30
szilles: shapes script should never been shown upright.
glazou: 3mn left on this topic.
szilles: we need to find a way to resolve the issues that are remaining.
szilles: it is not just the algorithm.
jdaggett: I can list the issues, not necessarily propose solutions.
* sylvaing did we have a list of the problems we intend to solve ? (no spec,
no properties, no spec - just requirements)
szilles: we can also discuss this at the F2F.
ACTION: jdaggett to outline the questions we need to address with regards
to text orientation in writing-modes.
<trackbot> Created ACTION-339
glazou: Topic: Scheduling?
fantasai: for writing modes, we have the ability to say explicitly if a text
is upright or sideways. There was a suggestion for alternative
syntax for code-points. I think we will not finish the spec. if
we go that way.
jdaggett: I think this is dependent on the other questions we need to
address.
fantasai: the other issue, is that the spec. says that if the font has
information about the orientation of the characters, then you
use it, otherwise you sythesize it from the rules in the spec.
appendix.
fantasai: most characters will be oriented properly, some may not be.
fantasai: if we want to define things in full details for automatic
determination, it will take another 6 months to 1 year.
fantasai: In the meanwhile, people are writing to the ePub spec and people
are not going to implement this correctly. The ePub spec will
track our behavior, not syntax. We will have an ecosystem that
will use the epub syntax and it is standardized.
jdaggett: There has not been anything defined so far that epub is going
down a specific way. I do not see a huge issue with the schedule.
fantasai: we are asking ePub to have a different syntax while we are
figuring out things that I do not think are critical.
jdaggett: the problems have not been worked out.
glazou: we need to take this offline or at the face to face.
<fantasai> http://dev.w3.org/csswg/css3-writing-modes/#text-orientation
sylvaing: I would like to see use cases that can be understood by me and
the rest of the group.
szilles: we are trying to define the default behavior.
sylvaing: I would like to see the requirements and use cases. They would
be helpful.
* ChrisL suggests sylvain express that in email
szilles: the original requirements came from Michel.
glazou: let's move this to email.
F2F
---
<glazou> http://wiki.csswg.org/planning/seattle-2011
glazou: we only have 6 agenda items for the meeting. We need more. I am not
sure if everybody has filled in the meeting page.
sylvain: I have 17 people registered. Please register ASAP. For the joint
meeting, I only have 30 seats.
sylvain: how can I modify the Wiki page?
<fantasai> you already have an account that you made with username sylvaing
sylvain: we have having issues finding extra rooms at the Marriott.
Will provide another hotel.
<smfr> did sylvaing say that the joint meeting with svg was thursday?
<ChrisL> svg wg registration results at
http://www.w3.org/2002/09/wbs/19480/SeattleJuly2011/results
szilles: is the courtyard fully booked?
sylvaing: issues on Sunday. Other days seem ok.
<ChrisL> @glazou agenda items for the FX tf day are here
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/agenda_proposals
sylvaing: joint meeting is on Tuesday.
sylvaing: there will be a hosted dinner on Sunday night.
<plinss> http://www.w3.org/Style/Group/2011/Seattle
sylvaing: we are interseted in flexbox, gradients and grids.
florianr: should we discuss single origin too?
we need jdaggett for that.
* BradK will not be able to attend in person, but I'd like to call in, at
least for certain topics (such as gradients).
jdaggett: I could dial in, but we need more progress before we can discuss
it again.
glazou: anything else on F2F?
<plinss> BradK, we can set up a conf call for any topics you want to call
in for, just let us know which...
Charter
-------
ChrisL: charter has been updated with the expected state in the next few
years instead of priorities.
<jdaggett> url?
<glazou> http://www.w3.org/2010/09/CSSWG/charter.html
<jdaggett> thx
<BradK_> Will I be able to connect to f2f via Zakim?
chrisl: charter has been sent to the AC. If there are no comments, will be
sent to AC for balotting.
Publication Requests
--------------------
glazou: Topic: 3 or 4 publication requests
glazou: CSS Device Adaptation from Florian.
florianr: we asked to have it published. We added all the pending issues
so it should be ready to publish.
glazou: objections to publish?
RESOLVED: publish the CSS device adaptation spec FPWD
glazou: deanj requested to publish css3 animations.
<glazou> http://lists.w3.org/Archives/Public/www-style/2011Jul/0157.html
fantasai: are the issues captured as issues in the draft?
sylvaing: we provided feedback that should be captured in the draft.
dbaron: I can also help.
ACTION: dean to add issues listing the remaining discussion points to be
resolved in css animation and css transitions before they can be
published.
<trackbot> Created ACTION-340
glazou: CSS3 speech ready?
daniel: not as a LC WD. I would like to ask if the WG has been able to
look at my proposal.
daniel: I need to align the css syntax with the ssml syntax.
daniel: the syntaxes are incompatible. The more contentious issue is to
add pre-recorded audio cues. I am still working on this.
<danielweck> last issue
<danielweck> voice-volume
<danielweck> speech synthesis versus pre-recorded audio
<danielweck> (will publish update later today)
<danielweck> yes.
glazou: we will discuss it again when Daniel says he is ready.
<glazou> http://lists.w3.org/Archives/Public/www-style/2011Jul/0126.html
glazou: the next issue is css3-ui.
glazou: Tantek resolved the issues from the last set of feedback. It
seems to be ready.
jdaggett: we need the editor to make a decision.
glazou: we'll ask Tantek to join next week.
glazou: could everybody review the css3-ui spec.
ACTION: all to review the css3-ui last draft.
glazou: call next week?
(most people are available).
glazou: there will be a call next week.
HTML5 LC
--------
bert: HTML5 issued a LC about a month ago. We should send comments or
say we do not have comments. We should start collecting our feedback.
glazou: there are a lot of things to say especially about the pseudos
that were never discussed.
bert: there is also things on rendering.
glazou: styling of placeholders.
bert: scoping as well.
glazou: it is undefined.
szilles: is there a list?
ACTION: glazou to send the list of HTML5 comments to the CSS WG before
the next F2F (Seattle)
<trackbot> Created ACTION-341
Meeting closed.
Received on Thursday, 14 July 2011 00:48:36 UTC