- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 22 Oct 2015 07:01:06 -0400
- To: www-style@w3.org
TPAC
----
- Anyone with items to discuss at TPAC is asked to please put them
on the agenda ASAP.
- The Japanese Industry meet-up is still short on details, but
Florian is speaking with them tomorrow, so hopefully they are
forthcoming.
Polar Orientation Property
--------------------------
- Jihye brought her proposal for a polar orientation property to
the working group for their feedback.
- The group felt that the effects of the property could be
achieved by the rotate property either as it stands or with
additional keywords aimed at handling polar cases easier.
- Florian also expressed a concern that the proposed behaviors in
polar orientation may not be enough to solve common use cases
and requested an issue be added that there may need to be more
keywords.
Writing Modes
-------------
- RESOLVED: Publish CR for Writing Modes.
word-break: break-all
---------------------
- Everyone agreed that the spec text for word-break: break-all
needed re-working, though there wasn't a clear decision on the
right direction.
- Koji and fantasai will come up with a proposed change to the
spec check referencing UAX14 and see what the group thinks of
it.
TR Stylesheet for W3C
---------------------
- The working group is in favor of any changes to the default TR
stylesheet that brings it closer to the stylesheet that the
CSS working group is already using.
Status of Unpublished Specs
---------------------------
- The Will Change and Variables specs have received resolutions
for publication, but have not actually been published.
- Bert will look into where these specs are in the pipeline.
- There are also specs with last publication date of more than 6
months ago.
- This issue will be discussed at TPAC.
Cascade 4
---------
- RESOLVED: Publish Cascade 4 as CR
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2015Oct/0173.html
Present:
David Baron
Bert Bos
Adenilson Cavalcanti
Tantek Çelik
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Jihye Hong
Koji Ishii
Dael Jackson
Brian Kardell
Myles Maxfield
Michael Miller
Edward O'Connor
Simon Pieters
Anton Prowse
Florian Rivoal
Hyojin Song
Alan Stearns
Greg Whitworth
Regrets:
Dave Cramer
Chris Lilley
Peter Linss
Lea Verou
Johannes Wilm
scribe: dael
Digressions/TPAC
----------------
glazou: Let's get started. This is the last call before TPAC
glazou: First thing as usual, digressions.
<glazou> https://wiki.csswg.org/planning/tpac-2015
glazou: TPAC agenda items. The list is pretty light as of a few
hours ago. I added a few, but it would be good if you
could add your requests to that page.
glazou: Do that ASAP so the chairs can have a good sense of how
much we have to discuss and some sort of prioritization.
Florian: The paperwork is in progress, so this isn't technically
true, but I'm switching to represent Vivliostyle. I also
have a valid consulting contract with Bloomberg. But I'm
no longer an invited expert, I'm Vivliostyle.
glazou: Anything to add to the agenda? We only have 3 items.
Polar Orientation Property
--------------------------
<jihyerish> https://lists.w3.org/Archives/Public/www-style/2015Oct/0177.html
jihyerish: Hi, I'm Jihye from LG Electronics. Above is the mailing
list message about polar orientation.
jihyerish: I proposed the property which could decide the
element's degree of rotation in a polar coordinate
system. It's named polar orientation and makes the
element rotate in that axis. It takes the values
center | counter-center| <angle>.
jihyerish: It works when it is positioned with polar distance and
polar angle property. When center is the given value,
the element rotates by polar angle value. If the anchor
is the center point of the element, a straight line
passing through the anchor point would meet the center
point of the containing block.
jihyerish: Counter-center makes it rotate by the polar angle value
plus 180deg.
jihyerish: Also, <angle> is used for polar orientation value type.
When the element has an angle value it has constraint
rotation transformation by specified angle. You can see
the results of the property by the example linked below.
<jihyerish> http://anawhj.github.io/jRound/demo/polar/rotate.html
jihyerish: You can see the sample of polar orientation in polyfill.
There are two circular layouts. In the left they are
without polar orientation. The right side is
implemented with polar orientation. All elements in the
circular shape have same polar distance. An element
with polar angle <90deg as center value. counter-center
is given to polar orientation when the polar angle
value is >90 and <270.
jihyerish: As you can see from the elements positioned at polar
angle 90 and 270, they rotate by a constant value of
0deg, no matter which polar angle value.
jihyerish: This is the explanation of polar-orientation. What do
you think about this property? Are there more things to
consider?
fantasai: This is, except for center center, is this the same as a
rotate property?
jihyerish: Yes, this property means the element rotates by Z axis
<dbaron> https://drafts.csswg.org/css-transforms-2/#propdef-rotate
fantasai: So rather than have a separate property that only works
when you're polar positioning, I think it makes more
sense if we need special keywords like polar-center, we
should add those to a rotate property which I think is
planned to be added. The angle values behave the same
way and we shouldn't have two properties that do the
same thing.
Florian: I had the same thought. If we keep it on a separate
property we should remove the explicit angle because
that's redundant with rotation. Center and counter-center
are not.
<dbaron> What was the intended initial value of polar-orientation?
<bradk> Transform: rotate(auto) ?
<fantasai> transform: rotate(polar-angle)
<astearns> it looks like you can do it all with rotation, you just
need to do the math
<fantasai> transform: rotate(counter-polar-angle)
<fantasai> transform: rotate(calc(180deg + polar-angle))
<astearns> rotate: polar-upright
<bradk> Upright = no rotation?
glazou: I have a question. Is there anything you can do with polar
orientation that you cannot do with rotation?
jihyerish: There is nothing we can do not using rotate, but when
you use polar orientation the user can specify the
rotation transformation more easily than using rotate
value when aligning elements in rounded display, I
think.
Florian: It saves you from doing math. If you want to keep the
polar angle and orientation in sync. If you have center
and counter-center it self-adjusts.
glazou: Yeah.
Florian: Which brings me to another point. As shown in the
example, it doesn't completely adjust automatically. On
the right you have a different value for the numbers on
the top, numbers on the bottom, and 4 and 10. Which means
you have to manually keep track of what is where. If you
have to do that I don't think the property is meeting the
goal. If you can set one thing to polar-orientation I
think you've met your goal. But if you have to set each
element you might as well use rotation.
Florian: Maybe we're missing a value or two, like an auto that
just handles the facing center. If the list of values
explodes, maybe it's not practical.
glazou: It seems there's consensus on the call and IRC that this
as a new property isn't a good idea, but a new value for
rotation is maybe the best thing.
smfr: One question is does it effect layout?
Florian: On the example everything is rounded. But if you stop
rounding and have corners, if you rotate that changes
what the polar distance has to be to avoid overflow. If
we're doing 100% with the value that makes it not
overflow then...
dbaron: Isn't polar positioning like abspos where it doesn't
effect layout outside?
jihyerish: Yes.
Florian: When you stack to one side the 100% value, like left 0 in
abspos, it puts you against the edge. If you rotate that
changes where you put it if you want to avoid overflow.
Am I making sense?
jihyerish: Yes.
Florian: So I think not being in rotate and being a separate
property makes sense for that.
fantasai: You'd want to have them evenly positioned outwards by
the centers because otherwise it looks uneven. You want
the centers even, not the furthest edge. So I'm not sure
I buy that.
Florian: Distribution, yes.
Florian: But I don't know. I'm not sure.
<bradk> On the list, there was a better way to avoid overflow,
which would make it not an issue here.
fantasai: I would say this is a case for using rotate and if we
want to add keywords to rotate to make this easier, I
don't see a problem. But two properties that control the
same thing is always a problem. If we want layout
effecting transforms that's separate.
Florian: This is separate. The way this would effect layout is
changing how percentages resolve in polar distance.
That's not the usual way of talking about layout
effecting transforms.
fantasai: I'll go with the if we need layout effecting transforms,
we make them, and not having this minor thing that does
layout.
jihyerish: Then you think the polar orientation is not useful
enough to be a new property?
fantasai: It's not about usefulness, it's about having something
solving one specific case and having a general property
that solves the same case. We shouldn't have this
special switch that does the same thing. If we need
additional keywords to make calculations easier, we can
do that. it's not good to have two properties control
same effect.
jihyerish: Okay, I got it.
Florian: One other thing I'd like as an issue is maybe we need
more keywords. Specifically keywords that automatically
switch between center and counter-center depending on
which half of the circle you're on. I don't know how many
variants, but I'd like an issue that says we need some
more.
jihyerish: I'll make that as an issue and think about it.
glazou: Anything else on this while you're on the call?
jihyerish: It's done.
glazou: Thank you very much.
Writing Modes
-------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015OctDec/0039.html
koji: The mail is from fantasai, but we think all the open issues
are resolved and edits are done.
koji: fantasai solved the last issue in SVG WG telecon. We want to
publish an updated Writing Modes CR.
Florian: Sounds good to me. We had a bunch of issues, we fixed them.
Florian: Small note, your bikeshed icon is red, so you should fix
that.
koji: You're right. I sent an e-mail to TabAtkins, but have to
follow-up.
glazou: I'm in favor of CR.
glazou: Other opinions?
<Florian> +1
<Bert> +1 to CR
glazou: Objections?
RESOLVED: Publish CR for Writing Modes
koji: Thank you.
fantasai: Cool.
word-break: break-all
---------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Oct/0124.html
koji: This is about word-break: break-all. This value was
originally proposed by Microsoft to allow Korean typographic
style.
koji: fantasai and I thought allowing breaks only between letters
works good. Blink included that and feedback from dev is it
was widely used in CJK and people want to break between
symbols.
koji: I tested and Firefox and Webkit breaks anywhere. IE doesn't
break before closing parenthesis and the like. I'm in favor
of following IE behavior.
Florian: So, as was said in the mailing list, the fact that IE
doesn't break before opening and closing parenthesis is
handled by the spec. Maybe that we use 'letter' in the
spec it doesn't allow breaking in the middle of a run of
punctuation, like ***. I think we should allow breaking
in the middle if it's not already allowed.
koji: The difficulty is what you pointed out. Since we don't
define line breaking rules exactly, our choice when we wrote
it was allowing only between letters can avoid breaking
before closing parenthesis.
fantasai: We an easily update the spec by, instead of saying
'letters', saying characters with unicode line breaking
collapse of AI, AL, H2, H3, HL, ID.
fantasai: The unicode line break spec seems to handle a lot of
these. The * is handled. I think they went through and
put everything under other characters as break between.
Other classes would continue to behave as they do
currently.
fantasai: [missed]
<fantasai> http://unicode.org/reports/tr14/#Table1
<fantasai> Proposal to switch restriction from "allow breaks
between letters" to "allow breaks between characters
from Numeric Context / Other Characters"
<fantasai> (roughly, might need to tweak for IS class)
<fantasai> (and RI class)
Florian: I can't verify that your list is correct, but the intent
is right and I trust you on the list.
koji: We have two choices. Add more line breaking places or say
places you shouldn't break.
Florian: I think shouldn't is handled via line-break: auto. We may
want to add a note to that value saying something like
restrictions should vary depending on language and are
important on some languages which don't use spaces as
separators. It's allowed by spec, but that might not be
clear enough.
Florian: For, me it's just a clarification. We have that the UA
should determine where it's not allowed. If the UA didn't
take into account requirements, that's their fault. We
shouldn't define where it's forbidden...it varies by
language and even in a single language there's variation.
But reminding the UA they need to care is useful.
koji: I'm not strongly against...line-break is switching between
levels, but it doesn't define basic levels. Second, I don't
think it's so controversial, breaking before a closing
period. it's not language specific. My understanding of
line-break: auto is break as much as possible unless it's
really bad.
<dbaron> maybe we should have this discussion next week when we
have better audio?
<tantek> agreed with dbaron
<tantek> also, debating line-breaking would be assisted by visual
examples
<tantek> in-person
fantasai: I think what we should do is look at the line breaking
classes and tailor them for word break. There's two
classes, ones by line-break and ones by word-break. I
think the only one in between is the small kana. The one
in the spec dealing with just letters is incorrect, but
UAX14 does that correctly. I think that will effectively
solve the problem.
koji: Okay.
Florian: I think we can give it a shot. I'm still a bit hesitant.
koji: Maybe fantasai and I work on the direction and come up with
proposed text.
Florian: Let's do that and see where it takes us.
koji: I think I'm okay with this.
TR Stylesheet for W3C
---------------------
glazou: If there's nothing else, we exhausted the agenda. Anything
else?
fantasai: Yeah.
fantasai: There was, there's a message on the survey about redoing
the TR stylesheets. I haven't gotten any response from
the WG.
<fantasai> https://www.w3.org/wiki/SpecProd/Restyle/Survey
fantasai: Are the chairs against having us answer, or is that
something we should do?
glazou: I'm leaving it to the new chairs. I didn't have a chance
to look at it.
fantasai: The deadline for the survey was a month and a half ago.
I need to have the stylesheet done by TPAC for it to do
anything, so it's a bit tough that we left it to when I
need feedback.
glazou: From a personal prospective, I trust you to do the right
thing. Personally I don't think we need to spend
conference call or mailing list time. Is there any
objection or is anyone willing to review the stylesheet so
we can come up with a WG decision?
Florian: I trust fantasai
fantasai: I'll do the best I can, but if you can tell me things
that need to be fixed that's also helpful.
glazou: No one objects. Let's record that it's a go ahead to
fantasai and we'll ping you later if there's something. Is
that okay for you fantasai?
fantasai: I'd like the WG to answer the questions about what they
do and don't like on the TR stylesheets. I'm sure people
have opinions and I can't account for them.
Bert: Question for fantasai. If I remember correctly the survey,
the things you proposed are things we already do in our
specs.
fantasai: Yeah. I do have more leeway since I'm doing it for the
entire W3C. If there's things we don't do because it's
too different from W3C, we have the opportunity to
change it.
fantasai: What are things we can do with CSS without changing the
markup that we'd want W3C wide.
fantasai: I will be merging in the CSSWG stylesheet, but since I'm
changing the entire stylesheet site-wide, things that
would make us inconsistent are now on the table.
<gregwhitworth> I personally love the CSSWG specs, the centering
of the text, a lot of white space, good contrast
and spacing.
Florian: I don't have a objection or desire for changing things
beyond what we do. I don't have a request for a change
beyond what the WG is using. I'll review something if you
want.
fantasai: It's fine if the WG has zero input, but it would have
been nice to know that a while ago. If there's nothing
to be said that's fine with me.
fantasai: If no one has any opinions on styling, we can say CSSWG
has no feedback.
Florian: Our feedback is we prefer what we use over what's on TR
and we support moves in that direction. Feedback beyond
that we don't have.
<fantasai> sgtm
Florian: Does my last sentence on IRC sound good as a WG position,
or is it just me?
<gregwhitworth> I agree
<koji> agree
glazou: I tend to agree with that.
<Bert> (I don't want the maximum line length, you know that
already; but otherwise fine.)
<fantasai> Yeah, that's a controversial one. I've got a handful of
people who don't want it and a bunch who do
glazou: I guess we won't push further on that since we can't hear
fantasai. Let's do that and move one.
Status of Unpublished Specs
---------------------------
glazou: There's still 12 minutes left
<fantasai> glazou, status of css-variables?
<fantasai> and will-change?
<fantasai> Also, http://www.w3.org/TR/css-cascade-4/ to CR
glazou: Status of css-variables and will-change.
glazou: There was an implementation in Webkit a few days ago, but
I guess this is part of a large topic. That is....for a
lot of our documents the TR document is older than 6
months or the ED is older. We have a lot of documents that
need to republish or give a clearer status.
fantasai: I'm concerned with these two.
glazou: Even if you're concerned with these specs only, it's a
wider issue. A lot of documents are ready for a new
publication and we need to discuss what to do with all of
them.
glazou: I'm guessing you want publication for those two?
fantasai: I don't. I want to know who is holding the ball. Why is
it not published as CR because it has been many, many
months. We have outstanding resolutions to publish these.
They were supposed to transition and they're not there.
Bert: It must be ChrisL or me. I don't remember which.
Florian: Or would it be TabAtkins?
<tantek> can we document how long it is taking from resolution to
publish CR to actual publication as CR?
<tantek> I would like to report this information to the AB
<tantek> seems like there are too many humans in the loop
<fantasai> css-variables is approaching 1 year
<tantek> and I want to cut this process down
<fantasai> and the problem there is people forgetting they need to
do stuff
<tantek> month+ between resolution CR -> TR CR is unacceptable
<tantek> and an embarrassment to W3C
<tantek> let me help fix this
<tantek> help me help you
<tantek> specifically the resolution -> TR time gap
<fantasai> tantek, they were held up on edits from Tab at some
point, and then I don't know whether they're held up on
him now or W3C staff
glazou: This is something we'll solve F2F at TPAC. There's a
moratorium anyway, so what we decide won't get the
documents published in the next few days.
glazou: There's nothing more we can do now.
glazou: I agree tantek, but stuff happens from time to time. Some
documents went under the radar for 8-10 years. It's bad
for everyone.
<tantek> under the radar is a different problem
glazou: Anything else for today?
<TabAtkins> No, I got all my edits in, and pinged Chris about them.
<fantasai> TabAtkins: will-change and variables both?
<TabAtkins> Yeah
<Bert> Yes. I'll see which documents are in the queue and check
with Chris.
<fantasai> Thanks, Bert.
<fantasai> I suspect it's just fallen off his radar
Cascade 4
---------
fantasai: Cascade 4 to CR? There were no comments.
glazou: Okay. Comments from people? What do you think?
<tantek> +1
<astearns> +1
tantek: If there's no outstanding issues, make it CR.
glazou: Objections?
Florian: I agree
RESOLVED: Publish Cascade 4 as CR
<fantasai> Bert, can you help Chris with the transition? (see above)
TPAC
----
glazou: Nothing else?
glazou: I wish you all a safe trip to Japan.
<tantek> see you all Tuesday morning
<tantek> I will be missing the first day (Monday)
glazou: This is my last call so you won't hear me too often.
<gregwhitworth> THANKS FOR ALL OF YOUR HELP glazou and plinss
glazou: Let's meet on Monday and for those going to attend the
Japanese Industry on Sunday, I'll see you there. We're
missing a few details on that. I got an e-mail on that
since there's no sign of life from the organizer. I'll try
and reach them before noon Sunday it will mean the meetup
is canceled or there's no info.
Florian: I'm meeting with organizers tomorrow, so I don't think
this will be canceled. I'll push for more details.
glazou: They need to send a message to this WG, all the chairs
(glazou, plinss, astearns, and rossen), and Marie-Claire
because she wants to share the info and cannot.
glazou: Safe trip everyone and I'll see you on Monday.
<Florian> thanks
Received on Thursday, 22 October 2015 11:02:06 UTC