- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Dec 2014 20:03:30 -0500
- To: www-style@w3.org
Styling Task Force
------------------
- It's confirmed that the new task force will meet on 7 and 8
February in Sydney, just before the CSS F2F
Sydney F2F
----------
- The wiki will be updated with nearby hotels
Box Alignment
-------------
- The group was evenly divided as to if 'true'/'self' should be
allowed in combination with 'stretch'.
- Several people expressed a desire to have more time to read up
on the issue before forming an opinion, therefore it was
decided to resolve on publication without 'stretch' in
<item-position> and move it back later once the group comes to
a decision.
- RESOLVED: Publish a new WD that doesn't have the changes, but
instead have an issue
Inline Layout
-------------
- RESOLVED: Publish Inline Layout WD
Counter Styles to CR
---------------------
- RESOLVED: Take Counter Styles to CR
findRule/deleteRule
-------------------
- RESOLVED: findRule and deleteRule will apply to the last
keyframe with a specified value (no change to spec)
- RESOLVED: For multiple values we expect the number and order of
values to match, but whitespace will be trimmed by browser. As
long as number and order is good, you'll get the last rule
that matches.
CSS3 UI pending edits
---------------------
- tantek will work on the pending edits this week
Flexbox and Tabbing
-------------------
- The group had a lot of concerns about the proposal to have the
tab order follow the visual order and gave a lot of feedback
of potential breakages with this change.
- bcampell will create a list of example websites and/or
screenshots to help further understanding and the group will
come back to this topic in the new year.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Bo Campbell
Adenilson Cavalcanti
Tantek Çelik
Dave Cramer
Elika Etemad
Simon Fraser
Sylvain Galineau
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Shinyu Murakami
Anton Prowse
Matt Rakow
Florian Rivoal
Simon Sapin
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Angelo Cano
Alex Critchfield
Daniel Glazman
Michael Miller
Lea Verou
Scribe: dael
Styling Task Force
------------------
plinss: Let's get started.
plinss: I got the additional items from fantasai and sgalineau.
Rossen: I have another about the inaugural meeting about the
whatever-it's-called task force
Rossen: Just a quick update, I have a number of replies. The two
days before the CSS F2F works for everyone. We will hold
the meeting in Sydney on February 7th and 8th which is a
Saturday and Sunday.
Rossen: shans will follow-up with exact location, but it will
probably be the same place. In the meantime we've resolved
on a name, so we'll create a ML and wiki soon. It'll be
similar to CSS meetings.
plinss: I'll ask about the domain for Houdini. You can start on
the extf name and we'll carry over.
<bkardell> I tried to jump in there but couldn't ... trying to
find out if we will be opening up WebRTC or a conf line
for that inaugural meeting
<tantek> Florian - re: CSS3-UI pending edits - planning to do a
block this week as other tasks have quieted down.
http://lists.w3.org/Archives/Public/www-style/2014Dec/0201.html
<tantek> Florian - please don't worry about writing patches for
the simple edits, it's easier for me to just do edits
directly than deal with all the machinations of applying
patches.
* Florian tantek: thanks.
* Florian Tantek: Can you join the call, since this has been put
on the agenda...
* Florian tantek: i misread your earlier message, and now see that
you will be on the call from 9:15. Ignore my previous
request to join, since you are joining already
Sydney F2F
----------
plinss: Do we know where CSS is meeting in Sydney yet?
TabAtkins: It's in the Sydney office.
Rossen: I thought it was on the wiki.
plinss: I looked, but maybe I missed it.
TabAtkins: It's all on one line that says place.
<dbaron> https://wiki.csswg.org/planning/sydney-2015 , under
"Place"
Rossen: Has anyone been to the office?
TabAtkins: Yeah. I can recommend any of the hotels in Chinatown.
Central business is maybe 15 min walk, but has nice
hotels.
Rossen: Central is to the east?
TabAtkins: Yes. Chinatown is to the south.
Rossen: Either is close enough to walk?
TabAtkins: Yeah.
plinss: If you can get actual names that would help.
Box Alignment
-------------
fantasai: Can you paste the link?
<plinss> http://lists.w3.org/Archives/Public/www-style/2014Dec/0267.html
<astearns> I'm assuming "'true'/'self'" should be "'true'/'safe'"
in the message?
fantasai: The issue is in the previous draft we didn't let
'stretch' combine with overflow. The issue is that this
doesn't make sense because 'stretch' doesn't respond to
the keywords.
fantasai: 'Stretch' is more similar to content-distribution
keywords. On content-alignment they can't combine with
overflow position keywords. You can have a fallback
alignment which can combine, but if you just just
specify 'stretch' there is no meaning.
fantasai: TabAtkins checked in with some changes to change how
things are organized and folded 'stretch' in and it now
means you can combine 'true' and 'safe' with stretch in
align-self.
fantasai: Do we revert that aspect, or do we want to allow this,
but only for align-self?
TabAtkins: And what 'safe'/'true' do, for a couple of the
alignment properties, if you do align-self it does, but
if it's bigger it goes outside and that might make it
go outside the scrollable area. We made these so that
you can say don't do whatever alignment you were going
to do, just allow the start alignment.
TabAtkins: 'Stretch' got in there, it's always going to be safe
anyway, but there are a few other values like start
that can't be un-safe. It doesn't do anything to have
'safe', but it allows it because calling out those
things would make the grammar more complex.
TabAtkins: This happened to make 'safe' and 'true' apply and it
doesn't do anything. That's what fantasai is objecting
to.
fantasai: I don't think the grammar is more complex, it parallels
the content property more.
<BradK> I would rather have complicated grammar than meaningless
values.
fantasai: TabAtkins and I don't agree, so you all need an opinion.
plinss: That you can't scroll in opposite direction is a bug and
we should fix that.
TabAtkins: Yes, but for now that's not the question.
dbaron: I think there's decent arguments on both sides. I can see
authors having a way of generating values for these
properties where you'd rather not deal with not producing
'safe' or 'true'. It also seems odd to have values that
don't do anything.
fantasai: Another issue is in the future we might want a fallback
for the 'stretch' keyword in which case the grammar
doesn't work the way it's supposed to. It doesn't work
in the way it does with content-alignment.
TabAtkins: We'd be in the same boat as align-content properties.
<astearns> I have a slight preference for not allowing a
meaningless combination of keywords.
TabAtkins: fantasai, one thing I realized is the baseline
properties that don't allow 'safe'/'true' will need it.
The last-baseline defaults to 'end' so you need to know
if it's 'safe' or 'true'. We need to apply those to
baseline so that would leave stretch as the only one
without.
fantasai: But in the baseline we have four values that don't
including 'stretch'. We need to be consistent.
TabAtkins: Or we can loosen on the other side. It won't do
anything because it will default to reasonable things.
fantasai: We need to have someone else speak up so we're going to
be quiet for 30 seconds.
* fantasai thinks people who have an opinion should speak up and
not just talk into the minutes
* astearns thinks that recording an opinion in IRC should be
sufficient :)
* dbaron hasn't really had the chance to digest the issue
<gregwhitworth> I'm with dbaron
<gregwhitworth> I would like more time
<Bert> (Sorry, still trying to understand the issue. :-( )
plinss: We have 4 people with opinions and we're evenly split.
bkardell: I'd echo dbaron. There's good arguments on both sides,
it's difficult to pull the trigger on one.
Rossen: Should we wait until next week. I'm in the same group as
dbaron. I haven't had a chance to review and absorb so I
can have an opinion. It's important enough that we
shouldn't just resolve for progress. I suggest doing this
over mail. We can have a deadline for mail.
fantasai: We want to publish tomorrow because that's the last
publishing date before the end of year. I propose we
revert the syntax to the old text, publish the spec
tomorrow, and keep this on the telecon agenda.
fantasai: I'd like it to be published and I'm okay to publish and
add this later.
Rossen: That sounds good if TabAtkins doesn't object.
<bkardell> this sounds p reasonable
<bkardell> +1
TabAtkins: I'll go with it.
plinss: I recommend that you revert and add an issue?
TabAtkins: We'll need to since we have to apply the baseline.
We'll pop something in there.
plinss: Everyone okay with publishing the WD?
RESOLVED: Publish a new WD that doesn't have the changes, but
instead have an issue
Inline Layout
-------------
fantasai: There was an issue about floats, I don't know if we need
to deal with that. Are we deferring?
dauwhe: I think so. ChrisL has already started the process.
fantasai: Okay. We'd like to publish a WD.
Florian: Now that I've reviewed, I've sent some comments about it,
some of which have been addressed already, but it's a WD
and it's going in the right direction so go ahead.
plinss: Objections?
RESOLVED: Publish Inline Layout WD
Counter Styles to CR
---------------------
* fantasai was pretty sure we had a standing resolution to take
counter styles to CR
TabAtkins: I haven't written the new DoC. There was one comment
during LC period. It was a comment asking us to add the
additional counter styles implemented by at least two
browsers. Made sense so I did so.
TabAtkins: They were present in the old draft, we had removed
them, I added them back and that was it. I've had no
other comments so I believe it's stable.
Florian: I'd echo fantasai's comment, but yeah.
plinss: Objections?
RESOLVED: Take Counter Styles to CR
plinss: Do we have tests for the new ones?
TabAtkins: I'm not sure if the existing tests do, but it's trivial
to adjust so that can be done.
plinss: That would be good. Standard CR period?
TabAtkins: Yeah.
* fantasai wonders where ChrisL is
findRule/deleteRule
-------------------
sgalineau: Last time we talked we agreed to specify what browsers
do as much as possible with the warning about a new API.
For these two methods, the key job is to define the key
argument, which is a keyframe selector
sgalineau: That can be single value, percent value or from/to
keyword.
sgalineau: That works fine across browsers. One thing we need to
agree on is if multiple rules match your selector,
which do you return? Webkit, Blink and IE return the
first, Gecko does the last.
TabAtkins: Other way around, I think. In the bug Timothy said we
switched to last.
sgalineau: Let me check.
Rossen: Can you paste the test?
sgalineau: Yeah.
<sgalineau> http://jsbin.com/jelili/5/edit?html,css,js,console
<TabAtkins> https://code.google.com/p/chromium/issues/detail?id=438387
TabAtkins: Here's the bug that said we switched.
sgalineau: The build I had returns first. So that means we have
two browsers doing each.
TabAtkins: We had two before, we're now three to one.
sgalineau: I don't think so.
TabAtkins: That implies we previously were three to one
sgalineau: I have three to one on doing it first.
sgalineau: Point is...is there a good reason to pick one or the
other? We need to pick. I think the last made the most
sense.
sgalineau: Now that we cascade the benefit isn't as obvious to
using last.
TabAtkins: I'm in favor of sticking to last since we switched.
dbaron: The code comment says, well, no it doesn't say why. It
just says last instead of first and references www-style
posts.
sgalineau: It used to be the last one had the effect so it was
reasonable at some point.
dbaron: I think the intent was the last one was the winning one.
<dbaron> http://lists.w3.org/Archives/Public/www-style/2011Apr/0037.html
sgalineau: If we do the last, does anyone from Apple or Microsoft
object to changing?
TabAtkins: In your earlier e-mail you said IE was returning the
last.
sgalineau: That was wrong. I tried remote IE and it did first.
sgalineau: The fact they can swing, I think we can change without
destroying anything. I'm happy with doing last.
Rossen: I wouldn't say I'm excited, but if we have to switch we
still have a chance. What about webkit?
smfr: We're fine switching
RESOLVED: findRule and deleteRule will apply to the last keyframe
with a specified value (no change to spec)
sgalineau: When you specify value, what browsers agree on is the
number and order must match the selector you agree on.
sgalineau: So are we okay with requiring the same order and the
interop issue today is that some browsers aren't happy
if you have spaces in there. You have to put your value
without spaces. I think we should get rid of that.
<bkardell> +1, that's lame
<dbaron> Gecko converts the selector to an array of floats and
then tests deep equality on the arrays.
sgalineau: You need to know the values and query in the same order.
So if the style sheet says 50%,75% you need to go in
that order. Is that are problem, or is it okay? That's
the interop today.
sgalineau: The main issue is the whitespace. everyone agrees that
the order must match. The whitespace is the only
weirdness. I haven't tried escaping and whatnot.
dbaron: Is there interop on from and to matching 0% and 100%?
sgalineau: Yes.
dbaron: And 100% matching 100.0%?
sgalineau: Good question.
dbaron: Gecko converts to an array of floats and does testing on
the arrays. That's how we handle both conversions.
* tantek Florian are we good re: Agenda item 3? Per
http://krijnhoetmer.nl/irc-logs/css/20141217#l-221 and
http://krijnhoetmer.nl/irc-logs/css/20141217#l-234 ?
smfr: I'd prefer we ignore whitespace which would be a change for
webkit, but I think it's fine.
sgalineau: So the user does the trimming?
smfr: Basically whitespace is ignored or normalized. I think that
would match expectations?
plinss: And normallizing float numbers?
sgalineau: It works in Chrome, I can check.
smfr: Webkit does it via string, so I suspect we would fail. I'd
be okay changing that.
sgalineau: Webkit and Blink are happy with 100.0. I haven't tried
firefox. It's reasonable.
<BradK> And 100% = 99.999999999999%?
sgalineau: So we're saying for multi-value...for single value it's
matching of number values. For multiple values we
expect the number and order of values to match, but
whitespace will be trimmed by browser.
sgalineau: As long as number and order is good, you'll get the
last rule that matches.
<dbaron> sounds good to me
RESOLVED: For multiple values we expect the number and order of
values to match, but whitespace will be trimmed by
browser. As long as number and order is good, you'll get
the last rule that matches.
CSS3 UI pending edits
---------------------
Florian: tantek said on IRC that he'd resolve them. Also, he made
a comment as to if I should write patches. I work better
if I work on an issue until it's over.
tantek: That's what the issues list is for. I keep notes on the
wiki.
Florian: So I'm not sure if you want me to do less...?
tantek: I won't use patches for simple things because it's faster
to make edits directly.
plinss: Let's not get into the weeds of editing techniques. It
sounds like you have how to do the edits done worked out.
tantek: I can get a big block done within the week.
Florian: Since there's a patch for everything it shouldn't take
long.
tantek: Well, the patches do take long.
plinss: You can sort that out offline
Florian: I just want to make sure we keep making progress.
Florian: We've been making a lot of progress on the telecons. I
don't want to bring this up again since its holding me up.
tantek: I think we went over it, so I don't know what else to
discuss.
plinss: I think Florian wants a commitment to keep up on edits.
Florian: I think that five things are done and another 23ish are
pending. I'm hoping it's not tied up too much in the
future. To be honest, I don't know why you don't like me
doing them. In the past you said you'd do them and it
wouldn't hold me up.
tantek: I typically edit in bursts. I'll get to a block this week.
plinss: I think when we discussed offline at TPAC, we just wanted
to set a reasonable time frame of something like 2 weeks.
I think that's the expectation.
tantek: Alright.
Flexbox and Tabbing
-------------------
bcampbell: Thanks to everyone that's been helping me. The problem
we've been having is when visual order changes the tab
order is following and there's a bug in Mozilla dealing
with residual order.
bcampbell: In a discussion, especially for screen reader, it
surprised me screen readers would like to follow the
visual order instead of the traditional path from the
DOM. So the tab order, I was proposing that it followed
the visual order.
bcampbell: The suggested wording is basically saying that rather
than saying the order doesn't effect the default, we
say that it does effect the order.
fantasai: The reason the spec is how it is currently is because
there's cases you want the order different and it's
better different and this makes it possible. If you
always follow visual, you can't have a different order
unless you futz with your layout. So if you have mobile
and desktop layout and you have desktop layout side by
side, but the logical order matches mobile, you want tab
to follow mobile.
fantasai: You don't want to just go left to right because that
visually looked better. You don't want to follow in that
case. There's another case where someone is using visual
to make changes that should have been at the source
level. If you tie them together you can't split. I can
see that maybe it's better because all the pages are
terrible, but are we giving something up?
fantasai: Should we never follow the source order or is it people
write bad pages?
fantasai: Are you saying that we should always follow the visual
order on principle and it's bad to do otherwise, or are
you saying that we should follow the visual order
because there are too many bad pages and we should
accommodate those at the expense of good pages?
bcampbell: That's a good question and a long one.
bcampbell: I think the suggestion is that, and I'd like to see an
example of what you talked about, we're talking about
the majority of the cases that are keyboard only. I
think that may be the weakness regarding how are the
majority using flexbox and just not knowing.
bcampbell: Having information that using flexbox for mobile and
we're causing an issue, I'd like to bring that evidence
back to the group. The way I'm seeing it right now,
they're asking for the same experience generally for
web pages. This allows nav-index to fall away, but to
change after that point we have to use tab index and
you're forcing someone to use tab-index through the
page.
fantasai: So an example would be something like the WG homepage
where there's a title, an introductory paragraph, and
then quick links to things you'd want to hit fast and
then we have short articles. We present linearly. When
you increase page width, we put the quick links side-by-
side on the left because that looked better.
fantasai: In this case you're saying tab order would do links and
then the introductory paragraph even though the logical
order is the opposite. We use order because you want
this on the left even though the source order is
different.
fantasai: I don't think you'll see this in column flexbox often,
but left or right for a visual person, there isn't quite
as strong of a this comes first. Sometimes these are
equally emphasized. Or here's the stuff on the side that
comes first, but I'll color it differently to make it
less emphasized.
<fantasai> bcampbell: Here's the layout I was talking about:
http://csswg.inkedblade.net/staging/redesign/divya/
<fantasai> bcampbell: (That page responds to media queries. Try
resizing it very large/very small.)
<fantasai> bcampbell, The example here in Flexbox shows the use of
reordering a column flexbox in an illogical way (
pulling an image up above its header):
http://dev.w3.org/csswg/css-flexbox/#overview
Rossen: I have a few things.
Rossen: What fantasai is explaining based on our experience with
windows store that use grid and flex to control
application layout. What we've seen and the feedback we've
received, controlling tabbing for magazine and news
related apps, the visual order isn't necessarily what's
desired.
Rossen: So if you have sections and sub-sections, you want to
navigate between the sections. So you have business,
sports, etc. before you tab inside a section. If you only
have visual order you have to go through all the business
before you get to sport.
Rossen: I would strongly suggest that you take that feedback/this
kind of feedback back.
<ChrisL> having to tab through all items of a list is even more
annoying.
bcampbell: Isn't that a huge problem for a keyboard user? If
you're jumping from section header to section header
and not going into the sections to interact. The
keyboard only user...
Rossen: You can always...this is somewhat in the hands of the app.
If the only thing you use for nav is the tab key, which is
hardly ever the case, this makes sense. But there's also
the direction keys where this hub selection makes sense.
bcampbell: I've seen a lot like this and this is a major challenge
right now. You have powerful shortcuts and you have an
advantage over a keyboard user. So you're saying each
section has a header, you have to do some code to get
the person into a section. It's another facet of
keyboard use. I understand what you're saying and I'd
like to research more
bcampbell: I'd really want to understand the impact of the
responsiveness of flexbox and when we're trapping
people into a particular flow if we flip this as
suggested.
bcampbell: I'd like to keep the conversation going and maybe bring
it up in the next meeting.
Rossen: I can point you to come windows apps that use complex
layout that use flex and grid and fragmented content with
regions where you'll have even more challenges. There has
been a lot of work done on our end and I believe the
proposal that you have will be quite limiting.
bcampbell: OK. I understand what you're saying. I want to get my
head around what you're saying and understand it really
well.
bcampbell: I see it in a different way. It'll take a long time to
explain, but maybe I can lay it out in a better way.
<bkardell> maybe it is worth collecting a bunch of use cases and
say how all are impacted by any choice
plinss: We'll come back to it in the new year.
tantek: One of the challenges I find in the discussion is there
aren't screenshots or URLs pointing to the examples. I've
seen many layouts that need something more complex than
sequential tabbing. I've seen it where you have to tab
through 100 links to get to the next section. If there's a
passion to fix this, rather than shoehorn an auto
behavior, I'd like to see documented cases.
<bkardell> +1 to what tantek is saying
tantek: A link to a real website where we can see, or at least a
screenshot that anyone can see. Anyone researching, please
document incrementally. That allows the best analysis and
participation from the group
Rossen: And to add to that, while the examples you brought was a
tab navigation through a visual map of something, that is
for me a pretty canonical example where tab reordering
would be the perfect tool to give an idea, like go through
in order of population size. The point is you have the
same set of data, but you want to change the order based
on the semantic you want to use. Visual only is limiting
there.
<ChrisL> tab navigation in maps is really poor
<ChrisL> yes, its active exploration not "go through everything"
<tantek> I wonder if there are any good examples of sequential
navigation for these examples.
<tantek> perhaps on a /sequential-navigation page on the wiki?
bcampbell: I agree in that situation, that makes sense. I'm trying
to speak for keyboard only users.
Rossen: We understand.
bcampbell: Let me try and get my research and I'll keep a running
place for the information and have a good way to have a
conversation. I see links people have been giving me.
<tantek> please keep the running documentation on the wiki
<tantek> not some offline file
<bcampbell> will do
<tantek> thank you bcampbell! appreciated!
<bcampbell> thank you
plinss: That's the end of the hour. No meeting for the next two
weeks. Happy Christmas, New Years etc. Travel safe. I'll
miss the first meeting of the new year.
plinss: Thanks everyone.
Received on Thursday, 18 December 2014 01:03:58 UTC