- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 25 Feb 2015 19:34:44 -0500
- To: www-style@w3.org
WebVTT Review
-------------
- Everyone should review the proposal and send comments to the
email thread.
Abspos Change Compat Risk
-------------------------
- Everyone present thought the change was still the right thing
and that more implementors need to make the change.
- Further discussion on the topic was deferred until next week
when more implementors are on the call.
CSS3 UI
-------
- Florian requested that everyone look over his proposed solution
to issue 69 (available here:
https://lists.w3.org/Archives/Public/www-style/2015Feb/0445.html).
- RESOLVED: Add some normative text to make it explicit that the
stacking of focus outline is left to the implementor
to provide better user experience.
- RESOLVED: Tighten the language of the directional focus property
behavior and include an informative note about the
behaviors we're considering and welcome/actively
solicit input.
Allowing @import to be conditional on @supports queries
-------------------------------------------------------
- RESOLVED: Add @supports to Cascade Level 4
- RESOLVED: Create an ED for Cascade Level 4
Logical Border Radius Properties
--------------------------------
- RESOLVED: Properties referencing corners drop the axis mentions
and go into the block axis first, for example
border-start-end-radius
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
Sanja Bonic
Bert Bos
Bo Campbell
Adenilson Cavalcanti
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Toru Kawakubo
Brad Kemper
Deirdre Lee
Peter Linss
Mike Miller
Edward O'Connor
Florian Rivoal
Simon Sapin
Greg Whitworth
Regrets:
David Baron
Chris Lilley
Dirk Schulze
Mike Sherov
Alan Stearns
Lea Verou
Johannes Wilm
Steve Zilles
Scribe: dael
plinss: Let's get started. Anything to add to the agenda?
smfr: I have something remove.
smfr: Transform-style 3d issue has been resolved by email.
plinss: Okay.
plinss: To start, happy birthday glazou
* dauwhe +1
WebVTT Review
-------------
plinss: There's been discussion on e-mail, but do we have group
consensus feedback to send? Do folks need time to review?
[silence]
plinss: I'll take that as a no. So everyone should review and send
comments on the e-mail. We'll gather feedback as a group
reply.
Abspos Change Compat Risk
-------------------------
gregwhitworth: We made the abspos change where it goes like 0,0
for flex items. Google docs has an issue. I posted
the flipboard issue. I've got two bugs open against
those.
gregwhitworth: I don't know what we do because I understand why we
have the change. I guess I wanted to make the group
aware of it.
fantasai: I thought the change was there to simplify what's going
on. If the old behavior is what's useful we might want
to go with that.
fantasai: I think we ran into issues with complexity where you
have a placeholder that has to follow layout and can't
affect order and there's an invisible thing adding space
so we took it out of flow.
fantasai: If websites want this behavior we need to dig into these
cases.
Rossen: I don't believe this is what people want, it's what people
have. They're using what they have.
Rossen: When we were discussing this in Sophia, we agreed the
simplified algorithm gets us quicker to better interop.
The abspos inline algorithm will be tricky, though
everyone had a implementation of it.
Rossen: I think what gregwhitworth is bringing is relevant and if
we stick to the current algorithm which I personally
prefer, then the question is are the other implementors
going to follow soon. If they do, this will basically
dictate when content will change.
Rossen: Does that make sense?
gregwhitworth: That's similar to what I was going to say. It's not
that they were asking for a specific use case, they
just happened to fall into it.
gregwhitworth: It's an unfortunate thing. The sooner all other
browsers change the devs will see it. I think we
should keep it because we're moving to better
layout.
fantasai: Okay.
fantasai: We need to hear from other implementers.
gregwhitworth: Is TabAtkins on the call?
TabAtkins: Yes.
gregwhitworth: What do you think?
TabAtkins: I haven't had the change to check with my team.
gregwhitworth: Why don't we circle back. dbaron isn't on.
fantasai: While we're on flexbox, TabAtkins did you sort out the
margins?
TabAtkins: I couldn't figure out where, so it was yesterday that I
did it. Let me see if anyone commented.
fantasai: That holds up publication.
TabAtkins: No response yet. I'll let you know when I do.
fantasai: We'll have to come back next week.
TabAtkins: Yes.
CSS3 UI
-------
Florian: We just got a WD out.
Florian: Also, I sent an email about issue 69 which was the long
standing one about box sizing.
Florian: I went through CSS 2.1 and figured out where everything
should be and wrote the patch and put into CSS3 UI where
it goes. We don't need to discuss, but I'd appreciate
review.
Florian: I erred on more explicit.
Florian: Things to discuss, issue 79
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Feb/0357.html
Florian: CSS3 UI doesn't define outline overlap. CSS2.1 does, but
it gives 2 options. Does anybody remember why we have 2?
All the browsers seem to do the same thing.
tantek: That's desktop only.
tantek: A lot of the looseness in outline has been based on
experience on platforms where outline is essential for
indicating user focus and that's not common on desktop.
It's common on TV or other devices with directional nav
like a remote.
tantek: The rendering of the outline was left looser in CSS3 UI
because platforms needed it for better UI. This is where
2.1 specified too much precision. On some platforms we
choose a better UI instead of strictly what CSS2.1 said.
tantek: That's the experience from like early 2000 to now on
non-desktop. It's important to keep that in and it's easy
to forget since it's non-desktop specific.
Florian: Okay.
tantek: That's the history. Maybe we should have a note that
mentions that. This isn't the first time it was mentioned.
Florian: I'd go even further since CSS UI doesn't replace. If we
have a note saying we don't define it's only in 2.1 If
you want looser it should be normative
tantek: That makes sense.
Florian: Do you have examples of current non-desktop browser?
tantek: Last I checked every set top box was violating it because
it's more important to have the line visible to the user.
It's not the easiest to set up, but I don't see why
browsers would regress their UI.
Florian: I was just trying to figure out why one is looser than
the other with no clear resolution. But do these TV UIs
do the same and we can spec that?
tantek: They did similar as of 10 years ago, but I don't have
modern set top devices to check today. My presumption is
they stayed similar, but I can't guarantee. I wouldn't
want to spec their behavior.
tantek: The other things is there's a lot of experimentations with
Web VR and we're going to want hooks into CSS. Outline and
Focus behave even more differently in 3D. I don't see this
converging.
tantek: Seeing the spectrum of implementation will broaden. We can
add some normative text to make it explicit that the
stacking of focus outline is left to the implementor to
provide better user experience.
Florian: I have no direct knowledge, but that sounds reasonable. I
think it would be better.
tantek: Since it's normative in 2.1 it needs to be normative here.
tantek: Two use cases are set top boxes and web VR.
Florian: Anyone else have something to add?
tantek: I would welcome input from anyone working on a non-desktop
platform, especially if you have experience with outline
rendering. More experience gives us more data.
plinss: Other opinions?
RESOLVED: Add some normative text to make it explicit that the
stacking of focus outline is left to the implementor to
provide better user experience.
Florian: If we have more time, I'd like to do issue 78.
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Feb/0344.html
Florian: This is about the directional focus property.
Florian: The way it's written, you can make something focusable
that wasn't before. It's not implicit, but it's intended
that the focus connector will match. I think explicit
wouldn't hurt.
tantek: Last time we discussed I thought we couldn't resolve on if
you did a nav up, should it make the element focusable.
Someone was arguing it should nav to the first focusable
thing.
Florian: That was fantasai disputing this. I think the current
intent is what you say.
Florian: The spec is currently implicit but ambiguous.
Florian: We should make the intent explicit and that a selector
should match, but we should consider that it makes things
un-focusable and focusable.
tantek: I agree with your conclusion, but I wanted to bring it up
since it wasn't consensus. I want to be upfront with the
group that those are the ideas on the table. Even if
Florian and I agree, the group should know about the
debate.
tantek: I want the group to approve or tell us to do more.
Florian: Both behaviors are useful and I'm not strongly minded
about which to choose. Which one should be the default
I'm not sure.
tantek: I'd rather a smart default instead of a switch unless
there's a use case that both are useful.
tantek: From that prospective, consider this a call for examples
or experience from anyone using directional focus
property, especially if you're using them for otherwise un-
nav-able properties.
tantek: We haven't heard a lot so far.
fantasai: Two other things. Existing implementations may have
content so we might not have a choice. Second is this
interacts with HTML and accessibility in widgets so
those people might have feedback. Making something
focusable without reflecting this in the HTML, is that a
thing we want in the web platform
<bcampbell> thanks for mentioning the accessibility implications,
would like to investigate further and help there.
TabAtkins: In particular some things are only focusable when other
things are the active focus.
tantek: fantasai's insight is correct that we might not have a
choice if implementations have converged here. If
implementations are different, then we can re-access and
understand why implementations are different.
tantek: In that case, content across implementations is unlikely.
Florian: In terms of current implementations I think they do agree
in terms of making un-focusable things focusable, but I
don't know what depends on that. There's nuance. If
you're doing through the keyboard it works, but not
anything else.
plinss: What does it mean to focus on something un-focusable? If
it can't take input what's the value?
TabAtkins: You can always do tabindex=url
tantek: That's already in the platform.
plinss: Seems like a bug. Should we perpetuate.
<gregwhitworth> IE: with tabindex-1 allows both active and focus
to work
<gregwhitworth> without, :active only works
tantek: I think we'll find out through testing. I wouldn't block
CR on this issue. Write a doc saying this is what we
think, test, and see how it falls out. If the tests show
implementations converge the other way we don't have a
choice.
fantasai: I think we should clearly document the issue and narrow
the scope. We're considering these ways, this is how
we'll decide, here's the background data, now it's down
to testing and implementations.
fantasai: That's what we can to push to CR.
Florian: Sounds fair.
tantek: I'm happy to have an informal note that saying we think it
should work this way and we need to test.
tantek: Normatively we should pick one so we can test and have an
informative note that says we think this is right and we
think this is what's being done, but testing will reveal
if that's true.
tantek: I think we have an idea of what we want to do and we can
have in the spec this is how you do this with informative.
Florian: I do think this is the right way, but I think fantasai
has a good point. I'm happy with the current, I'm okay
with it, I'm not sure I prefer.
tantek: If there's feedback before CR we'll take it and if it's
after we'll take it.
<Florian> clarifying my point above: I am ok with the current
behavior, but I am not sure I prefer it over fantasai's
suggestion, so I would definitely welcome author
feedback (and feedback form HTML and accessibility)
fantasai: I think you should ping HTML, accessibility and maybe
TAG for more feedback since it's a where's the boundary
issue.
plinss: I'd especially like to hear from accessibility.
<bcampbell> I am unable to cut in on the phone but can volunteer
to bring this to a greater group for accessibility.
TabAtkins: If you're doing a game UI or something, this is very
useful. It shouldn't limit focus to things you can type
into.
fantasai: The issue isn't about the nature of focusability, the
interesting question here is can CSS be a mechanism for
this and without it being reflected any way in the DOM.
If it's purely CSS that effects if this can be focused.
tantek: I think TabAtkins disagreed with the game example, such as
getting focus and then getting event.
fantasai: TabAtkins's example could be done with HTML.
tantek: It might not be a bug.
Florian: Which is why I'm inclined to say both is reasonable and
we should have a switch for it in the future.
tantek: I agree we shouldn't do a switch now. Tighten the language
of the behavior and include an informative note about the
behaviors we're considering and welcome input?
plinss: Objections?
fantasai: And also actively solicit input. Don't just put it in
the spec and expect feedback.
tantek: That's reasonable.
RESOLVED: Tighten the language of the directional focus property
behavior and include an informative note about the
behaviors we're considering and welcome/actively solicit
input.
plinss: I accept that focusability may be something you want only
in CSS, but I don't like these features that are side
effects of other features. I'd like us to create specific
property that says we're taking control of this. You can
always have that behavior actually set. I don't like
magical properties that are side effects.
<fantasai> plinss++
tantek: I think I had a property in an earlier CSS3 UI and it was
dropped for lack of interest or objections. What we're
dealing with is we have directional nav supported. This
seemed the best result. In general I agree with your
philosophy. We can try and introduce it in 4.
Florian: The switch you suggest is what I have in mind, so I agree.
plinss: I think this is something for 4 since 3 is heading to CR.
Florian: I think we're okay with CSS3. There's another, but it can
go in e-mail.
tantek: Is that clip?
Florian: Yes.
tantek: It does seem editorial. So yeah, that should be it.
<tantek> Note: resolutions for CSS3-UI issues 78 and 79 captured
https://wiki.csswg.org/spec/css3-ui#issue-78 and
https://wiki.csswg.org/spec/css3-ui#issue-79 as discussed
earlier in the telcon. Thanks for everyone's input.
Allowing @import to be conditional on @supports queries
-------------------------------------------------------
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jan/0292.html
TabAtkins: We have multiple conditional rules, but the number of
places that invoke media queries explicitly only
involve @media, so you can't import a stylesheet that
has new features. Right now you have to include
everything inline,
TabAtkins: So my proposal is extending the grammar to support the
other conditional rules. You can do a straight media
query or you do a supports function.
TabAtkins: Boris pointed out that in order for this to be useful
we'd have to be stricter in spec that says you don't
load @imports speculatively. You only load if it
matches.
TabAtkins: So I propose to extend the @import grammar so it can
support any grammar.
TabAtkins: Also tighten up the language in CSSOM as to where in
the cascade we load conditionally imported style sheets.
TabAtkins: Any comments? Otherwise I'd like a resolution
<gregwhitworth> yes please!!!
fantasai: Seems like a good idea.
fantasai: It seems necessary and reasonable syntax. Add to Cascade
4?
TabAtkins: Yes, I'm fine with 4. This isn't urgent, it's useful.
<fantasai> TabAtkins, I think either Cascade 4 or Conditional 4
would make sense. Cascade lets you mess around with
@import handling rules a little more directly.
<fantasai> TabAtkins, Cascade 3 is in CR, pretty stable. Think
it's fair to bikeshed 3, then fork off 4 to add this.
<fantasai> (Would definitely bikeshed 3 first, so 3 is bikeshedded
onto /TR)
Bert: I think it's a cool idea. I was wondering you said don't
load the stylesheets because you're risking whatever. I
think more and more loading unconditionally because privacy
concerns. Do you not expose anything about your browser by
not loading?
TabAtkins: No more than you do with scripts.
TabAtkins: Even without script you can use the standard put the
background image with a URL pointing to something on
your server trick. There's no additional privacy
concerns.
plinss: It is part of the fingerprinting surface, but it's already
exposed through other means.
Bert: Background images aren't conditional anymore. Webkit
recently fixed background of scrollbars because they were
exposed. Okay. I just wanted to think about those.
TabAtkins: If you have script, you can evaluate MQ whenever you
want so exposing more doesn't hurt.
fantasai: I'm thinking we should bikeshed Sascade 3 and work up
level 4 so we can maybe add this and also introduce
default.
TabAtkins: We do need to add default.
plinss: Anyone object to adding @supports?
RESOLVED: Add @supports to Cascade Level 4
TabAtkins: Can we get a resolution for level 4 ED?
fantasai: If you bikeshed 3 first and then fork it.
TabAtkins: Yeah.
RESOLVED: Create an ED for Cascade Level 4
fantasai: Do people want to resolve on default now?
TabAtkins: I'd rather do that on the list.
fantasai: Okay.
plinss: Anything else?
Logical Border Radius Properties
--------------------------------
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jan/0313.html
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jan/0327.html
TabAtkins: Was that fantasai or was that from Cameron?
plinss: Cameron brought it up.
plinss: Anyone want to talk on it?
Rossen: What about?
fantasai: Naming conventions. border-block-start-order-inline-start
-radius is really wrong.
fantasai: There was a convention to do block first. We would just
want to resolve on that.
TabAtkins: Sounds good to me.
fantasai: I posted the proposal in IRC.
plinss: Okay. Any thoughts about adding this?
Rossen: Sounds reasonable.
TabAtkins: As part of the logical properties it would logicalizing
most things. It would be let's use this pattern for
things that are extra long.
Rossen: fantasai and I have quite a bit of work on that spec. This
is good input and makes sense.
fantasai: This would be the pattern for things that reference
corners.
plinss: Okay. Want a resolution?
fantasai: Proposed resolution: properties referencing corners drop
the axis mentions and go into the block axis first, for
example border-start-end-radius
plinss: Objections?
RESOLVED: Properties referencing corners drop the axis mentions
and go into the block axis first, for example:
border-start-end-radius
Rossen: Is fantasai's auto-sizing of ruby not on the agenda
anymore?
plinss: I think we did it at the F2F
plinss: Anything else?
fantasai: I have DoC for flexbox and a couple more issues were
raised. Upcoming will be dealing with that, but it's
mostly done.
plinss: That's a future call?
fantasai: Yeah. Probably next week.
plinss: Alright, everyone gets 10 minutes. Thanks.
Received on Thursday, 26 February 2015 00:35:12 UTC