- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Mar 2015 17:53:43 -0400
- To: www-style@w3.org
New Publication Process
-----------------------
- ChrisL introduced the new tool for publication, Echidna, and
said that the beta version should be available for people to
look at shortly.
Upcoming Meeting Dates and Locations
-------------------------------------
- New York on 18-20 May was reconfirmed.
- RESOLVED: Mozilla does August meeting in Paris.
- RESOLVED: Provisionally accept Aug 25-27 (Tue-Thu) as the
meeting dates.
- RESOLVED: Pencil in week of Feb 1st for 2016 meeting.
CSS Ruby
--------
- fantasai will clarify the vertical layout section.
- Reverse-propagating style to the parent appeared to be the least
bad way to address whitespace between ruby boxes
- RESOLVED: Use locale-specific :lang() rules instead of something
like webkit-ruby-size for bopomofo ruby sizing
- RESOLVED: ruby-position simplified to over|under|inter-character
- RESOLVED: Either option 1 (Change initial value to center. Reset
it for Japanese to be space-around in the UA
stylesheet) or 3 (Have a value that does custom
justifications - auto - which justifies between Han
and Kana, and not between bopomofo) for ruby-position,
at editor's discretion, WG preference to 1 if no legacy
problems exist.
===== FULL MINUTES BELOW ======
Scribe: TabAtkins
New Publication System
======================
ChrisL: Existing publication system is a piece of shit.
ChrisL: It takes html => tidy => xhtml => php => composter:
produces error messages as a primary function.
ChrisL: Then when it's free of error messages, ask someone else to
do the same exact thing and disagree with you.
ChrisL: This is not a good model.
ChrisL: Replacing it with echidna.
ChrisL: The source tool is in github so you can look at it, change
it, etc.
ChrisL: Been in alpha, about to go into public beta (tomorrow,
hopefully, or today in Australia, who knows)
ChrisL: Been testing it today with CSS3-UI.
ChrisL: But that spec is cursed. Breaks everything.
ChrisL: Benefits:
ChrisL: Publish any day. All 7 days.
ChrisL: Can publish multiple times per day; last per day will be
retained.
ChrisL: Downsides: First beta won't do CR, only WD.
ChrisL: It won't do cross-WG publications yet.
ChrisL: Those'll be worked on.
ChrisL: But no FXTF stuff yet.
ChrisL: No human in the way to complain about your stylesheet.
astearns: "last per day will be retained"?
ChrisL: If you publish and notice a problem, you can just fix it
and nobody will know.
ChrisL: But with more than 24 hours, you're screwed.
ChrisL: Cutoff is midnight Boston Time
heycam: Does anyone get the right to push the button?
fantasai: Everyone but Tab.
ChrisL: Anyone can. There's a token system? I don't understand it
well.
ChrisL: afaik there's nothing preventing chairs from giving it to
the editors.
heycam: Any documentation?
ChrisL: HAHAHAHA
ChrisL: Yes, somewhat.
ChrisL: I'll find it.
<dbaron> https://github.com/w3c/echidna
<dbaron> https://github.com/w3c/echidna/wiki
krit: If something goes wrong, will someone fix it?
ChrisL: Yeah, it's an official systeam product, they'll fix it.
SimonSapin: Does that mean we can have max-width:50em on our
stylesheets?
ChrisL: Don't know. As long as the checker doesn't complain, you
can probably get away with it.
ChrisL: Currently something we have to take out when we publish is
the tests script.
ChrisL: W3C is now allowing those scripts, and not under the
directory it's published in.
ChrisL: I scared the system by first asking for a W3C mathjax
install. When they said no, I pointed out we have 60+
individual mathjax versions all bitrotting, and they
capitulated.
ChrisL: Bert is maintaining mathjax, Peter will maintain the
results script, and I'll talk to Lea about prism.js.
ChrisL: So over time there'll be several approved scripts people
can just use.
krit: Can we get a `bikeshed publish` command?
ChrisL: Sure, probably.
tantek: When will we see the first draft?
ChrisL: Maybe tomorrow.
tantek: How long until we can publish CRs, joint work, etc.
ChrisL: A few months.
astearns: Since FPWDs trigger review too, does that mean they
can't do it yet either?
ChrisL: Dunno. Probably.
<ChrisL> some documentation
https://github.com/w3c/echidna/wiki/How-to-use-Echidna#current-limitations
<ChrisL> in case anyone wondered, our cuddly new publication
system is named after this:
http://answersafrica.com/wp-content/uploads/2013/10/echidna2.jpg
Upcoming meeting dates and locations
====================================
glazou: Next meeting is confirmed in New York, 18-20 May.
<astearns> https://wiki.csswg.org/planning/new-york-2015
glazou: We still have to discuss end of August.
TabAtkins: People tell me Zurich is a hellhole in August.
dbaron: And it's gotten very expensive lately.
TabAtkins: Right. So what about Paris?
dbaron: Note that everyone leaves Paris in August.
TabAtkins: So cheap hotels?
dbaron: Also some restaurants will be closed.
<liam> no, because people from other countries flood in, just as
the French go to Italy and the Italians all go to Greece :)
TabAtkins: So it sounds like Paris is the best idea.
[general assent]
plinss: Let's nail down dates. Currently Aug 24-28 blocked out.
dino: What about Houdini?
Rossen: 1-2 days. We'll work it out on the ML.
TabAtkins: So, suggestion from Tantek is that Firefox hosts Paris
August instead, and Google just does Sydney again next
Feb.
<tantek> TabAtkins, well, it was more of a floated idea to
consider
<tantek> TabAtkins, dual motion
RESOLVED: Mozilla does August meeting in Paris.
<dbaron> SimonSapin, re: the room in Paris, both double-check with
Shannon *and* book the room in the calendar
<SimonSapin> dbaron, will do
TabAtkins: Dates!
Florian: Suggest 24-26
SteveZ: Possible conflict on 24, maybe do 25-27
heycam: Next scheduled SVG meeting is June in Sweden.
heycam: Don't think we're meeting between then and TPAC.
RESOLVED: Provisionally accept Aug 25-27 (Tue-Thu) as the meeting
dates.
tantek: Tentatively block out next Feb meeting as first week of
Feb?
RESOLVED: Pencil in week of Feb 1st for 2016 meeting.
<tantek> with Google hosting in Sydney
SimonSapin: Feb 1st is FOSDEM.
glazou: I can't do after Feb 20
<tantek> getting away from Valentine's Day is a plus
ChrisL: That'll conflict with my 20th wedding anniversary.
dbaron: This year, the week before this week was a more expensive
for flights, because of Australia flight patterns, though
that went away closer in.
<TabAtkins> ADJOURNED
<Rossen> br { @extends .break; action: resume; }
CSS Ruby
========
Scribe: shane
Line Height Rules
-----------------
dbaron: There was discussion on the mailing list - agreed on line
height rules. But it's not in the spec yet.
fantasai: It seemed like that made sense.
fantasai: I will try to write it up and grasp it fully.
dbaron: With some of the prose for figuring out what this means in
terms of vertical placement/sizing I couldn't figure it
out.
xidorn: There's an open bug about how height in ruby base
container can be determined.
dbaron: Prose in spec about how this can be determined. OK for
ruby text container but ruby base container should act
like an inline as much as possible.
fantasai: I think ruby base container in terms of how it effects
line layout should be like an inline, but in terms of
how it effects the spacing of ruby annotations on either
size need to take into account border padding and margin.
dbaron: I'm ok with that.
dbaron: Part that's weird is sizing of the content box is not like
an inline.
fantasai: Right. Sizing of content box should include margin boxes
of all of the bases.
dbaron: Is that because you don't like how inlines work?
fantasai: I don't like that margins don't effect layout for those.
fantasai: If you put borders on ruby bases, having that not effect
position of ruby text seems wrong.
fantasai: How does the author get it right then? line height?
dbaron: Fine with it to move the ruby text.
fantasai: The simplest way to keep things from colliding is to
have the ruby base container contain all of the ruby
base boxes and text container (?) contain ruby text and
stack them with no gaps.
dbaron: If you don't want line height to effect ruby position that
makes sense.
SteveZ: But ruby has to effect line height.
dbaron: I'm OK with that.
xidorn: Does vertical align property effect ruby text?
fantasai: Yes.
xidorn: But how?
fantasai: I don't remember scoping. Ruby text at same annotation
level with align with each other.
dbaron: So basically ruby text container acts like a line for
purposes of alignment.
SteveZ: So what connects lines?
SteveZ: Will I get strange behavior if I put non-ruby stuff
between two things?
SteveZ: e.g. underlines don't jump around. Concerned that Ruby
might act different. I don't know what should happen
though.
fantasai: <draws on board>
SteveZ: What if one of the letters was bigger?
fantasai: <more drawing>
fantasai: Basically you do the sizing of the characters, then the
base box wraps around that, then the text sits on top so
it's always aligned.
SteveZ: Why isn't the ruby text box a line box the whole line
long?
xidorn: Another concern is the line height of the anonymous ruby
text container. In the current model it should inherit
from its parent. But I don't think it is desirable.
fantasai: I think you're right. We shouldn't be using properties
of the ruby text container for layout. We should be
using the ruby text, then wrapping the container around
the result.
dbaron: Be careful about difference between line box and inline
box. Inline box has a line height but line box wraps
around a bunch of inline boxes and takes height from them.
dbaron: I think what you're saying makes sense. More complicated
but OK. Put in spec please?
fantasai: What's not in the spec?
dbaron: Vertical alignment.
fantasai: I'll just check.
fantasai: I need to fix that then.
dbaron: That's the biggest set of issues I was worried about.
dbaron: I would like to see spec edits resulting from discussion
with xidorn and koji though.
Whitespace Between Ruby Text
----------------------------
fantasai: There's a couple of hard issues.
fantasai: Handling whitespace between ruby text. Problem is that
if you've got ruby text that you've marked up but
there's whitespace in-between. Want the whitespace to
stay there but I size the ruby text elements to 50% of
base text. But then whitespace ends up being really tall
and really wide and the wrong size.
Florian: That's not something we can fix.
fantasai: Yes, HTML people don't like autogenerating tags.
fantasai: That's the issue I haven't really figured out how to
solve.
dbaron: Is it possible to say that the whitespace goes away but
that there are other spacing rules for ruby text?
dbaron: For example, what script they're in, whether script has a
certain property.
dbaron: Such as newlines go away in Chinese.
SteveZ: Does that mean you want to put another character than
whitespace in?
fantasai: I think you could reasonably argue that those rules
could get rid of the whitespace but there are other
cases where you don't want it to.
fantasai: The issue is that we want font set on the outer box but
instead it's set on the inner boxes
[because the outer box isn't marked up]
Florian: Can we reverse-propagate style to the parent?
dbaron: We've never done it before.
astearns: Any other reason we'd want to style the text container?
fantasai: Possibly?
fantasai: We do forbid you from making ruby text and ruby base
containers visible.
fantasai: This is because some implementors will want an
internalized structure that's different from the CSS
hierarchy.
fantasai: Styling those boxes isn't an important use case.
fantasai: It should be fine to have different internal model.
fantasai: So boxes aren't directly detectable, can only inherit
properties through them.
astearns: Can you say line height of container is max line height
of children?
SteveZ: That doesn't work. Really want to set it to font size of
children.
SteveZ: Only concerned about whitespace between?
fantasai: Yeah, everything else is wrapped.
Rossen: Is this really a common use case?
fantasai: It isn't an error condition but it isn't common.
SteveZ: Classic one is where you have double ruby (english + ??).
English one would need the spaces.
SteveZ: Would be common in English ruby.
fantasai: I'm not sure what the rules are in pinyin.
Florian: Some syllables need to be separated by an apostrophe if
there isn't a space. Otherwise it's stylistic.
Florian: If the only purpose of propagating up is to propagate
back down again that seems like the least bad idea.
fantasai: Agreed. I'll use that for now. If anyone thinks of
something better can change it.
Locale-Specific :lang Rules
---------------------------
fantasai: Next issue. Webkit has a special keyword for
ruby-font-size. Inter-character generates smaller font
than above or below.
fantasai: Resolved as locale-specific rule in stylesheet for ruby.
Florian: Is by language not by script. Close enough?
fantasai: Can do it by :lang(). Can set font size explicitly if a
problem. This is just for default size.
Florian: OK
RESOLVED: Use locale-specific :lang rules instead of something
like webkit-ruby-size.
Ruby-Position Property
----------------------
<Florian> http://upload.wikimedia.org/wikipedia/commons/c/c7/Hunmin_jeong-eum.jpg
fantasai: Next issue. Ruby-position property had 2 keywords for
position in horizontal text and for vertical text.
fantasai: Suggestion was to simplify to a single keyword for both
(over, under, inter-character)
dino: We have after, before, inter-character
fantasai: That's definitely wrong.
fantasai: If we have single keywords, then over implies right,
under implies left, and inter-character implies right
for vertical text.
Florian: This example shows inter-character for vertical text.
fantasai: Can extend back to two keywords if necessary.
fantasai: But this is the common case.
fantasai: Can we resolve to do this?
Scribe: TabAtkins
SteveZ: My understanding of the problem of translating above/below
to vertical is that traditionally Japanese does right (
above) but some Chinese cases go left.
fantasai: That's why we had two values, but Xidorn says we don't
need them.
xidorn: I don't see any left cases.
xidorn: You don't have any pictures of left.
xidorn: I don't know what use-cases you've found.
fantasai: This is stuff I inherited from the previous editor.
I don't know the use case myself.
fantasai: The difference between over/under and before/after is:
fantasai: If you have block-flow of vertical text laying out right
to left, before is right, after is left. If the blocks
stack left to right, vice versa.
fantasai: But over/under depend on what way text is rotated, not
block-flow direction.
fantasai: So proposal is to knock it it down to over|under|
inter-character, and we can add more in the future if
needed.
dbaron: What was the two-value syntax?
<xidorn> [over|under|inter-character] || [left|right]
fantasai: Would let you specify left|right as well, so one's for
horizontal and one's for vertical writing.
Florian: The current proposal combines them.
RESOLVED: ruby-position simplified to over|under|inter-character
ruby-align
----------
fantasai: Next is default value of ruby-align
fantasai: Two values are center and space-around.
fantasai: space-around is a justification value.
fantasai: It add space at the justification opportunities.
fantasai: So Latin text would stay together, but Chinese would be
able to split between each character.
fantasai: So we set the initial value to space-around.
fantasai: Problem is that bopomofo can be justified, but bopomofo
ruby should be centered by default (due to language
users preference).
fantasai: 1) Change initial value to center. Reset it for Japanese
to be space-around in the UA stylesheet.
fantasai: 2) Keep it as space-around, reset it for Chinese to
center.
fantasai: 3) Have a value that does custom justifications - auto -
which justifies between Han and Kana, and not between
bopomofo.
fantasai: Spec is currently 2.
fantasai: But multi-word ruby you may not want to justify spaces,
so maybe 1 or 3 is better.
fantasai: It seems only Han/Kana should be justifying.
TabAtkins: 1 seems simple then.
SteveZ: 3 is the classic way we do it, but it requires magic.
fantasai: I don't think 3 is too magic, but 1 is definitely
simpler.
fantasai: Main concern with 1 is "do we have a concern with legacy
untagged content?"
SteveZ: 3 is script-based.
SteveZ: Why is 1 better?
fantasai: Simpler. 1 is just a 1-line fix to your UA stylesheet; 3
is effectively a new justification algorithm.
TabAtkins: Can we just do 1 unless we see evidence of breakage in
the wild?
fantasai: Dunno what Koji wants. Let's do 1 unless Koji dissents.
RESOLVED: Either option 1 or 3 for ruby-position, at editor's
discretion.
ADJOURN FOR REALZIES THIS TIME
Received on Wednesday, 18 March 2015 21:54:12 UTC