- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 21 Jan 2015 21:00:34 -0500
- To: www-style@w3.org
Flexbox Accessibility
---------------------
- BCampbell brought his revised proposal for addressing the
accessibility concerns created when Flexbox changes the visual
order of the boxes and the tab order.
- The new proposal is to create a method for authors to
designate if the order is important so that only those
items with the important signifier will have their tab
order changed in line with the visual order.
- There were several questions about the implications of the
proposal and clarifications about if a change is even needed.
- Another suggestion what the the directional nav-* properties
from CSS3 UI might help address some of the issues.
- Several people brought up that this issue seems larger than just
Flexbox and has been around since early CSS.
- It was agreed that this topic would be best solved at a F2F
meeting. bcampbell said he'd try and make it to Sydney, but
likely it would have to wait until NYC in May.
Grid Layout Issues
------------------
- RESOLVED: align-content and justify-content on grid containers
operate on the grid tracks (allows distributing extra
space between grid tracks)
CSS3 UI
-------
- tantek will make note of the outstanding issues and objections
in the WD so that they're a part of the publication
- RESOLVED: New WD of CSS3 UI
Color & Background Serialization
--------------------------------
- RESOLVED: Accept the proposed change for the serialization order
for <final-bg-color> (available here:
https://lists.w3.org/Archives/Public/www-style/2014Dec/0194.html)
Floats & Initial Letters
------------------------
- fantasai brought her and dauwhe's potential solutions for when a
float is interacting with an initial letter.
- SteveZ raised an alternate proposal that he thought might handle
the problem a bit better
- Several people were unsure as to which proposal is best without
visual examples, so this topic was also declared a good fit
for the F2F in February.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Bo Campbell
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Koji Ishii
Dael Jackson
Toru Kawakubo
Brad Kemper
Chris Lilley
Peter Linss
Michael Miller
Edward O'Connor
Florian Rivoal
Andrey Rybka
Simon Sapin
Alan Stearns
Lea Verou
Steve Zilles
Regrets:
Sylvain Galineau
Simon Pieters
Keshav Puttaswamy
Ian Vollick
Greg Whitworth
Scribe: dael
glazou: Let's start
glazou: Anything to add to the agenda or discuss before we start
to official agenda?
glazou: There's one item from koji, but I'm not sure we'll have
time.
<tantek> glazou: I'd like to prepare a CSS3-UI draft for
publication before the f2f
<glazou> tantek: ok, will put that between items 2 and 3
<tantek> thank you glazou
Flexbox Accessibility
---------------------
bcampbell: Let me paste the wiki.
<bcampbell> https://wiki.csswg.org/spec/css3-flexbox/accessibility
bcampbell: After posting some arguments and replies, it was my
example that I put in with a trivial flexbox that was a
diagram, I agree it was trivial and we need to address
the holy grail of layout.
bcampbell: I did some research on that and realized it says the
sequence of the containers in this layout has no
meaning and therefore rearranging visually has no
consequence. We have an argument against that from Matt
King in IBM who is somewhat of a spokesperson for the
blind and he's said that he wants it to work for the
blind.
bcampbell: After seeing that there's real need and a meaningful
sequence, I talked to Richard and a developer on a high
profile IBM app to understand why we have this issues
and what exactly they want. Flexbox has the opportunity
to be powerful for designers that need to move things
visually and not get developers to change the code.
bcampbell: There's several examples that I can site where data
comes into the client and you're able to arrange the
data using Flexbox. Those developers are crying out
about losing the Mozilla "bug" because they're not
going to update or use tabindex to go through.
bcampbell: So we have a complex, rich application, like an e-mail
app, so that's the other side of the power. To go back,
the argument to force browsers to update tabbing order
is what I'm hearing from the disabled community.
bcampbell: From Richard and I's discussion, what we need is a
parameter to tell if the sequence is meaningful or not.
If it's not meaningful, we can stay with the old way.
When it is meaningful, we need to be able to tell the
browser that it is and switch the tab order.
bcampbell: The proposal has changed more to allow Flexbox to have
the power of doing it either way.
bcampbell: I have two questions to ask. The first one is if we
have anyone that knows today how the backlog is for
complaints about the way Mozilla reorders for Flexbox.
The bug has been around for a long time and I'd love to
know if it's a huge point of contention.
bcampbell: I'd also like to understand better, and everyone has
been good at explaining and helping, but I'm wondering
in this holy grail layout, starting tab order in the
middle of the content and page, what situation does a
user need to do that?
bcampbell: I'm from a standpoint of just people using a webpage,
not people with a disability. In general I'm going to
assume this isn't a huge deal.
bcampbell: I'll open it there.
<dbaron> Is this discussion supposed to be primarily about tab-
order, or also (which I thought was more important) about
reading order?
glazou: tantek?
glazou: dbaron go ahead.
tantek: Sorry I was muted. I'm hoping this is one of the areas
where directional nav can help such as when there's a
scenario when the author...
tantek: uses Flexbox to move things and the tab order is non-
obvious and not fixable by the browsers, but the author
can say I know where things belong.
bcampbell: I'm unfamiliar with the spec language that you mean.
tantek: Directional nav-* property in CSS3 UI. Let me get a link.
<tantek> http://dev.w3.org/csswg/css-ui-3/#nav-dir
<astearns> http://dev.w3.org/csswg/css-ui/#nav-dir
tantek: Take a look at that and see if it could help from
authoring side.
bcampbell: Interesting.
<astearns> directional navigation is separate from tabbing, yes?
<fantasai> astearns, yes
<fantasai> I think creating an 'order' property was a mistake, it
should have been 'visual-order' if only affects the
visual order.
dbaron: One thing about this discussion was that there was...a lot
of the discussion seemed to be about tabbing order, but
we've been talking about what is the logical order in
which to read the content or do anything other than how
you put it on the screen along the x and y axis
bcampbell: I think what you're referring to is the visual order
may be different than logical. The answer I got on that
was mainly from Matt King. He was adamant that all
screens should follow the pattern, left to right, top
to bottom. That is not necessarily the visual flow on a
screen, but it's the flow screen reader users
understand. That's where it starts to get subjective.
bcampbell: You can manipulate that via visual hierarchy, but I
think that argument when you get to those who want it,
they want it the way its always been.
dbaron: At some point what you said is you want a switch that says
if you want things in the order as reordered by order or
in the original order? I think 'order' is that switch.
dbaron: The idea of order is the DOM should be in the logical
order. If you want the visual different you use order to
manipulate that.
bcampbell: But if you use order to manipulate the visual order,
this is the basis of what we're talking about, then you
have a tabbing order that jumps everywhere. If the
visual is meaningful to the viewer, you need the
sequence of the tabs to flow in a meaningful direction.
dbaron: If it's meaningful, they shouldn't be using order, they
should do the DOM in that order.
bcampbell: In principle I agree, but that isn't how it's being
used and it's sort of unreasonable in a larger, agile
team environment.
bcampbell: The other part is developers are finding that the speed
of CSS to move things is faster. Inside of IBM on high
profile apps it's that they're using Flexbox in any way
they can. That has tons of implications and breaks
things for those with a disability. Without a switch to
say we want to change the order and say that we want
this to flow in a meaningful way, they need that to get
the benefits.
bcampbell: If the idea is to not have those benefits for Flexbox,
how do you get people not to mess things up for those
with disabilities?
bcampbell: Can I understand the arguments against adding a switch
other than dev should be doing good coding? I think
we're stretching CSS and if it's moving in this way
with Flexbox and Pseudo Elements I think we'll have to
change the stance of updating the DOM backwards.
<leaverou> Not having tabbing order follow that order that reduces
its usefulness. For example, if you pin posts in a
forum with order: -1; wouldn't you expect tabbing to
respect that? I can't think of any case where you would
want tabbing to follow the source order
* leaverou (but I can only get part of the discussion, so feel
free to ignore of the above doesn't make sense)
<fantasai> leaverou, the argument we're making is that you
shouldn't be using 'order' for semantic reordering
<fantasai> leaverou, which is very clearly stated in the spec, but
hasn't been reflected in e.g. your favorite tutorial
<ChrisL> you shouldn't be using 'order' for semantic reordering
<leaverou> fantasai: no matter what we evangelize, authors *will*
use it that way, just like they're using :before and
:after for semantic content too. proper accessibility >
semantical purity IMO. Also, what *is* non-semantic
reordering? Is there any example of that? (sorry if it
has been mentioned, I keep dropping)
<fantasai> leaverou, consider main vs navigation sidebars. Putting
sidebar on left or right is a visual decision that
shouldn't affect navigation/speech order
<tantek> bcampbell: can you provide a URL to one of these high
profile app examples that we can look at ?
* bradk doesn't think CSS should be an excuse for bad HTML
<tantek> bradk I agree and you should say that on the record
* fantasai agrees with tantek's point about speaking up :)
ChrisL: fantasai made the point in IRC, you shouldn't use 'order'
to modify the semantic order, it's designed for visual.
There are things used for alternate reading orders. It's
all very well to say the content and DOM should be in
natural reading order.
ChrisL: Say you have a map and the reading order depends on what
part of the map you want to look at. If you want heights
you can tab through that, or shops and tab through that.
There isn't only one right order. Reordering the DOM all
the time also isn't a good answer.
bcampbell: I think what I pinpoint is when you say stuff like
should, I get that. I agree that you should do it the
right way. I'd like to look at the directional-nav
properties.
bcampbell: What I'm seeing from all sides is that this flexbox
tool could be a great possibility for what designers
can do. To go back to all these teams and say no, I
guess that is an option, but I'm hearing loud voices
that say flexbox is awesome for these things, but a11y
says flexbox is killing us.
* glazou thinks we should speed up a bit, already 18 mins on this
* fantasai it's a complex topic, I don't think there's much speed
to be had
* glazou fantasai if it needs more, it’s a good ftf item
* fantasai it's def a good f2f item, I think
* tantek agrees with fantasai, and notes that this is perhaps one
of the very important aspects of flexbox. also +1 to f2f
discussion to see the problematic layouts in person.
* Rossen agree to spend longer time on this during f2f
* dauwhe is NYC in May too late?
bcampbell: The simple solution for everyone is to allow people to
use flexbox. I'm sort of beating a dead horse. The
argument to add a parameter, if that's on the table,
the argument is that you shouldn't be adding things in
that order.
astearns: I have an argument about adding a switch.
astearns: Having a flexbox specific switch is a little too narrow.
We considered a switch that changes the way pointer
properties go in display order rather than DOM. We
should consider a switch that allows us to change tab
for all the ways we can manipulate display.
TabAtkins: Caring about order is a narrow view that doesn't
address the problem. There's lots in flexbox that
causes problems. We need to address visual order rather
than DOM order directly. Maybe that's a CSS property or
maybe it's something for a11y.
bcampbell: That was part of the problem. If you're changing the
visual order it needs to be accessed by the a11y tree.
That sounds like a huge undertaking that can take a
long time.
TabAtkins: Not necessarily. That's the answer, there's no way
around it. In order, you can force direction in upwards
or rightwards direction, that reverses your normal flow.
The assumption that DOM table order will match visual
order isn't really valid with advanced layout.
fantasai: It's worth noting with MQ, the visual order can change
depending on the device or as I change the width of the
browser window. If you want to insist that you want it
to go strictly left to right top to bottom in this size
for this device, but if I change device or screen width
I want to change the reading order to match that
different order, then that should be a screen reader
feature that reads the page in strictly visual left to
right top to bottom order, and handles all the different
ways of repositioning items (including flexbox, grid
positioning, floats, abspos, etc.. Any way you can get
things out of order, if you want that visual order you
should have a feature that does that.
glazou: bcampbell will you be in Sydney?
bcampbell: Not unless I can make a good argument for it.
glazou: It seems to me this is an excellent topic for a F2F
bcampbell: I agree. I can work on it, but I doubt it. That's a
good question. NYC if we don't have a resolution before.
tantek: We've been able to rearrange content in CSS for a long
time. This isn't Flexbox in particular, it sounds like
you're finding new examples. Links would help us see if
it's a new problem or the same old one. Presentation vs
DOM problem has been around since CSS1
<ChrisL> yes, floats have provided reordering since forever
bcampbell: The question is if Flexbox doesn't give you more
flexibility, why have it?
tantek: It gives you more flexibility. The problem case we've had
floats doing this since forever, positioning, tons of ways
before flexbox. If we want this semantic order we
shouldn't monkey-patch, we should solve.
bcampbell: I completely agree.
tantek: I think that's why people are asking for it at a F2F
<astearns> all the other ways we've been able to reorder display
have been hacks - using features not meant for layout.
Flexbox is the first feature meant for layout, so
keeping tab order consistent with the intended layout
is a bit more important than before
glazou: I'm sorry we don't have a conclusion, but I suggest we
move on.
bcampbell: This move more forward another step. I'll see about the
F2F. Thank you.
glazou: If you can't make Sydney, let's do it in NYC.
<bradk> Is there any reason why nav-index can't solve this?
<bradk> Nav-index: visual-order
<tantek> bradk nav-index was a poor design, and only addresses the
tabbing problem
<tantek> or only *tries* to
<tantek> er, *tried*. sigh.
<astearns> bradk: using nav-index along with order is a
maintenance nightmare
<bradk> Expand nav-index to affect screen readers too then
<tantek> bradk, astearns: if anything I'd prefer to brainstorm a
'nav-next' property similar syntax as 'nav-up' etc.
<tantek> bradk - now that's crazy nav-index spooky side-effect
from a distance stuff! :/
CSS Grid Layout Issues
----------------------
glazou: Rossen you requested a week on this.
Rossen: I'm okay with it.
<Rossen> we did re-review it one more time internally and are OK
with the proposed change
glazou: So, who raised the issue? Was it you fantasai?
fantasai: Let me try and remember it.
fantasai: The issue was we wanted to update the spec so
space-around and space-between creates space between the
grid tracks. That gives us some useful functionality and
is consistent with how items are thought about.
glazou: So Rossen says he agrees.
glazou: Objections?
<andreyr> no obj
RESOLVED: align-content and justify-content on grid containers
operate on the grid tracks (allows distributing extra
space between grid tracks)
glazou: Okay for everyone?
[silence]
CSS3 UI
-------
<Florian> I am joining now
<Florian> give me 1 minute
tantek: Thanks to Florian help we've made good progress with
resolutions. I would like to publish a draft before the
F2F.
<fantasai> Publish early, publish often
tantek: I'd like to both continue to resolve the issues and
anything we can't resolve in time I'll incorporate inline
to the spec. I wanted to see if that plan is amenable to
the group and, if so, I'll follow that plan and have
something for next Wednesday.
ChrisL: Sounds good. Can I have it by Tuesday for the publication
queue?
tantek: I can do that, but I wanted to let the group review. If
people are okay with what's there and the continued
progress, that's fine with me too.
ChrisL: If you have it for Tuesday, I can put it in the queue and
if we don't resolve on Wednesday I can pull it out.
tantek: Okay.
glazou: Anyone object to the publication?
fantasai: I'm in favor.
TabAtkins: I think it's reasonable for Florian to be a co-editor
with everything he's put into the draft
tantek: I'll make sure Florian is acknowledged.
tantek: Florian has put a lot in, but there's been a lot before.
I'll give Florian proper acknowledgment.
* dauwhe agree wtih TabAtkins
glazou: To add to what TabAtkins said, I think he should be a co-
editor, but we won't spend the rest of the call on it.
He's doing major work. Lets go back to the main subject.
* fantasai agrees with TabAtkins and glazou
<ChrisL> I agree it makes sense for Florian to become co-editor.
And +1 to publish
* tantek TabAtkins glazou fantasai ChrisL I will definitely your
suggestion under strong advisement. I'll discuss with
Florian also.
* ChrisL @t thanks
RESOLVED: New WD of CSS3 UI
Color & Background Serialization
--------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Dec/0194.html
glazou: That was from Sebastian Zartner.
<leaverou> I think it makes much more sense at the end, because
it’s *underneath* the background image, so it follows
the order of the rest of the bg layers
TabAtkins: I can do this. Apparently, currently the grammar for BG
puts the bg-color at the end of the last layer. The
serialization matches the grammar. Apparently Firebug
users prefer it at the front. Are we okay with
switching the serialization around? Is that a compat
thing?
<leaverou> is there any reason to put it in the beginning besides
people asking for it? Did they provide any rationale?
dbaron: You're putting the color at the beginning of the last
ident instead of the end of the last.
TabAtkins: Yeah. That's what he's asking for.
TabAtkins: I'm reading dbaron's comment on it. It sounds like it's
to make the code simpler.
TabAtkins: I don't care either way. It's a tiny change. fantasai
should be the one worrying about accept or reject.
smfr: Any feelings on the compat risk of this?
TabAtkins: No feelings.
dbaron: Are browsers interop now?
TabAtkins: I'm testing Chrome.
TabAtkins: It's only asking to rearrange the serialization of the
last layer. It's not a meaningful change.
glazou: The main question isn't how the browsers are serializing.
Are there frameworks that parse it and expect the color at
the end?
TabAtkins: No idea. Chrome puts the color at the beginning.
smfr: Same with webkit.
dbaron: Which implies it's fine the change.
<Rossen> can you share the tc?
fantasai: The reason for end is that it's painted at the bottom of
the bg layers and the bottom layer is the last with
multiple layers. That's the original rational.
TabAtkins: I'm either insane or Chrome has a completely broken
serialization of the bg shorthand. It looks like we're
100% broken.
TabAtkins: This is what I get...I don't know how we completely
broke that, but it's crazy times.
dbaron: We didn't get the "this".
<Rossen> TabAtkins: can you share your test case pls?
* TabAtkins rgb(255, 0, 0)
url(http://software.hixie.ch/utilities/js/live-dom-viewer/foo),
url(http://software.hixie.ch/utilities/js/live-dom-viewer/bar)
repeat, repeat scroll, scroll 0% 0%, 0% 0% / auto,
auto padding-box, padding-box border-box, border-box
* TabAtkins background: url(foo), red url(bar);
TabAtkins: So ours is an error.
TabAtkins: It does look like color is first.
??: So there's not that strong of dependences on how this is
presented.
glazou: So are there objections to the change?
[silence]
RESOLVED: Accept the proposed change for the serialization order
Floats & Initial Letters
------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Dec/0166.html
<ChrisL> initial letter I18n examples from richard ishida
https://www.flickr.com/photos/ishida/sets/72157650248400402/
fantasai: When dauwhe and I worked on initial letters, we
discussed a lot of things already, but not how to deal
with if there's a float on the first or second line of a
paragraph with a two line drop cap.
fantasai: We went with the float clears the initial letter as if
the initial letter was a float.
fantasai: Other options were float is between the initial letter
and the rest of the text. Or it fits between initial
letter and the rest of the text.
fantasai: I think there's a reasonable argument for at least two
options. If the float is on the first line and not the
second, it's awkward no matter what.
fantasai: If you want an image at the beginning you can put it
before the paragraph with the initial letter.
fantasai: Generally an image is an item on it's own.
fantasai: I wanted to see if there's other feedback
<tantek> aren't such floats usually FOR the initial letter
SteveZ: I sent you another interpretation on the ML which is to
say we should treat the initial letter as defining what
the first line or current line is which means the float in
the second line would move to the front and up because
it's part of the initial letter sequence.
SteveZ: The argument is the initial letter has moved the line it's
shortening so it's part of the same sequence. It would
give you a fairly reasonable handling of most cases, even
with shorter lines.
Florian: I was with you until the last thing.
SteveZ: That would be okay because it would float beneath the
initial letter.
Florian: I thought it would get to float below.
SteveZ: It's not perfect, but I think better.
fantasai: I think it's an interesting interpretation. You can get
yourself into interesting floats because the float might
be on the second line, it fits on the second line, so it
should shift left and it fits, but then when you move it
up it doesn't fit anymore because the first line is now
also shortened.
SteveZ: You might need logic like that in Regions, so you make
your decisions and if the layout changes, you ignore that.
fantasai: I'd like dbaron opinion.
Rossen: Sounds like a lot for doubtful benefits. The layout logic
is quite complicated for something that's complex enough.
<Florian> floats are hard enough already
SteveZ: It's no worse than two floats on one line.
Rossen: If the initial letter is a float, yeah.
fantasai: no
SteveZ: The alignment is different, but it's basically a float
<dbaron> we should be moving away from treating the initial letter
like a float
<tantek> dbaron meaning ::first-letter ?
<dbaron> tantek, yes
fantasai: Floats depend...you never move a float up. You can
decide if it fits, as you layout the text you see if it
fits on the line and if it does, great, and you shift
the position. If it doesn't fit you push to the end of
the line and continue layout.
fantasai: If you move it up, you can't do that. Here's my line #2,
it fits, great, but we have an initial letter so you
have to push it up, shorten the first line, and then you
have to re-layout and the float may no longer fit. So if
you're not moving up you can layout, but in this case
you have a cyclic dependency.
SteveZ: It's no worse than you have to take the length of the
lines being shortened by the drop cap.
tantek: I think we should capture this as an outstanding issue. I
think it would also benefit from F2F visual discussion.
Florian: Use cases would be good
<fantasai> I want to note that if you want to put a float in the
top left corner, you can already do that
<fantasai> Just put the float before the paragraph
dauwhe: I haven't seen an example where there's this possible
interaction so I want to do a search for that.
Florian: I think Steve's proposal is sane, but it's harder, and to
see if it is worth solving, I'd like to see use cases.
Otherwise, fantasai's solution is simpler, and also sane.
dauwhe: I also think initial letter is different than a float.
tantek: I also see Rossen's concerns about adding complexity
without real world examples.
dbaron: What we need to solve is let's not have cases where the
spec says there should be a result that's unachievable,
but else wise I agree.
tantek: I think with an addition that we find that out from impl
experience.
dbaron: We already know that it is.
<dbaron> I think the simple solution is saying that a float that's
not in the first line and intersects (i.e., on the same
side as) a drop cap clears below the drop cap
<fantasai> dbaron, that's exactly the proposal dauwhe and I have
<SteveZ> My proposal is documented in:
http://lists.w3.org/Archives/Public/www-style/2014Dec/0277.html
fantasai: To summarize. I think your idea is interesting, but it
introduces a complexity in floats that doesn't already
exist. It also can create a loop. I think this is a bit
of an edge case. Lastly I agree with Rossen that this
doesn't seem like a really important thing to solve.
That complexity doesn't seem to be worth dealing with
for such an edge case that is rare in practice.
fantasai: That's why I think you have an interesting idea, but not
a good idea for us to go with.
tantek: I don't know which is better because there's a lack of
examples.
SteveZ: I thought we were waiting to the F2F to solve
dauwhe: I can make diagrams. Cool.
<ChrisL> diagrams++
fantasai: Anyone want to pursue SteveZ case?
<astearns> let's wait until the ftf to decide, including steve's
proposal
Florian: Without examples, no, but if he has examples maybe.
tantek: I can't answer without examples.
SteveZ: I also have to understand putting the float before the
drop cap a bit better.
<Bert> (Also seems asymmetric to me: you might to move up when
floating left, but probably not when flowtimnmg right...)
<fantasai> <img> <p>Drop cap paragraph/p>
<fantasai> img { float: left;
<fantasai> Done. Puts it in top left corner of paragraph
CSS3 UI
-------
glazou: We're at the top of the hour
Florian: Quick question on CSS3 UI. There was one resolution that
we made that was objected to. If we pub without changes
that's fine, but I don't want to make edits and change
them.
tantek: Issue 40?
Florian: No. If we publish, publish as is and don't roll in the
edits.
<Florian> I cannot hear you
tantek: I can capture the objection. I'd rather have the edits in
and capture the consensus and the objection.
<tantek> this is about Issue 47 resize (I think)
<Florian> it is about issue 47
<tantek> need URL to the objection
<Florian> it's in the wiki
<tantek> great. thanks.
<Florian> Objection was from Tab and smfr.
glazou: I'm lost. What are you waiting for tantek?
tantek: Nothing.
glazou: Okay.
glazou: That's it for today. Talk to you next week and thank you
very much.
Received on Thursday, 22 January 2015 02:01:05 UTC