- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 28 Jan 2015 20:23:09 -0500
- To: www-style@w3.org
Transitions
-----------
- dbaron asked that everyone review the Transitions ED since he
hopes to bring it up for publication at the F2F.
Next Week's Telecon/Sydney F2F
------------------------------
- Since both chairs, and likely many others, will be traveling
next Wednesday, there will be no telecon.
- Everyone was reminded to add items to the wiki for discussion in
Sydney.
Where is the "Complete Document"
--------------------------------
- RESOLVED: Turn the old road map into a 301 redirect to /TR/CSS
and discuss updating /TR/CSS at the F2F
Flexbox
-------
- RESOLVED: Use 'content' as the new value for flex-basis
- TabAktins explained his rational for creating 'no-wrap' as an
alias to 'nowrap' to alleviate author confusion. However, the
group remained unconvinced as to if it was the best way
forward. This issue will remain open while the explores more
possibilities and look for more information.
- The remaining flexbox issues still need some work and/or
understanding before they're ready for the group, though they
should be ready by the F2F
extending break-* to lineboxes
------------------------------
- Fantasai brought her proposal for extending the break-*
properties to control inline layout. It received a warm
reception as an idea worth exploring.
text-wrap: balance
------------------
- The text-wrap: balance proposal was also well received with a
lot of people showing interest in developing it further.
- fantasai stated that she and astearns will be bringing their
unofficial ED for CSS4 Text to the group shortly to formalize
it.
CSS3 UI
-------
- RESOLVED: Change the must into a should and remove the reference
to "may ignore" for issue 38
(https://www.w3.org/wiki/CSS3-UI#Issue_38)
- RESOLVED: Document ime-mode as obsolete as described in the
draft
- There was discussion on changing the language for ime-mode to
say browsers should not support, however that wasn't resolved
upon so the resolved upon publication will go forward with
existing language and the "should not" language will wait for
a formal resolution.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Sanja Bonic
Bert Bos
Adenilson Cavalcanti
Tantek Çelik
Dave Cramer
Elika Etemad
Daniel Glazman
Tony Graham
Koji Ishii
Dael Jackson
Toru Kawakubo
Peter Linss
Michael Miller
Shinyu Murakami
Anton Prowse
Florian Rivoal
Simon Sapin
Dirk Schulze
Alan Stearns
Lea Verou (IRC only)
Greg Whitworth
Steve Zilles
Regrets:
Angelo Cano
Sylvain Galineau
Chris Lilley
Simon Pieters
Keshav Puttaswamy
Mike Sherov
Ian Vollick
Scribe: dael
Transitions
===========
plinss: Let's get started. Morning/evening/afternoon. Anything to
add to the agenda?
<glazou> plinss: next week’s call
dbaron: One thing is I'm hoping to ask for Transitions to LC/CR
relatively soon, probably at the F2F.
fantasai: Can we push a WD to TR first?
fantasai: Is it up to date?
dbaron: I don't think there's need to push another WD.
fantasai: The things we should look at are on TR?
dbaron: They're in the ED.
fantasai: I think it would be good to push to TR and make a broad
announcement.
dbaron: Most of the updates are for implementors.
tantek: I agree with dbaron. If it's ready to go, that's how you
get people's attention. Just go.
Next Week's Telecon/Sydney F2F
===============================
plinss: Anything else?
plinss: I'm going to talk about the F2F. Both glazou and I will be
on a plane during next week's call, so I propose we cancel.
plinss: We'll need more items for the agenda, so please update the
wiki. If there's any last minute logistics, please bring
it up.
Where is the "Complete Document"
================================
plinss: TabAtkins you were talking about this on www-style?
<TabAtkins> No one can hear me...
* plinss no, we can’t.
florian: Is there anything else besides turning this into a gutted
note?
fantasai: I think it should be a redirect
fantasai: A gutted note isn't useful to anyone. A redirect will
put people some place useful.
<Bert> q+ to support fanatasi's suggestion
<dauwhe> +1 to fantasai
Florian: You'd have the link to the old discussion if there was
anything useful.
tantek: I agree with fantasai. Just point to the thing people are
looking for. Else wise it looks like bureaucracy.
<dbaron> /TR/CSS/ is almost 5 years old at this point
<dbaron> er, 4
fantasai: We can add a previous draft link if we have to. I want
to to be a 301 permanent redirect. No aliasing.
Bert: I'd like to suggest we don't just add a redirect, but also
update /TR/CSS.
fantasai: I agree.
fantasai: Let's add that to the F2F agenda.
Bert: I won't be there, but it sounds like a good topic
fantasai: You can send us your advance ideas.
<tantek> +1
fantasai: Proposal turn it into a 301 redirect to /TR/CSS
plinss: Anyone object?
Bert: Both can happen, but it's easier for the webmaster if the
update happens at the same time. Depends on how quickly.
tantek: I guess onto the 301.
RESOLVED: Turn the old road map into a 301 redirect to /TR/CSS and
discuss updating /TR/CSS at the F2F
transform-style: preserve-3d creating containing blocks
=======================================================
plinss: smfr are you on the call? I guess not.
Flexbox
=======
<fantasai> Summary of open flexbox issues:
https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0071.html
E-mail Text:
"Need the WG to resolve on:
1. Adding a 'no-wrap' keyword that means the same as 'nowrap'.
https://lists.w3.org/Archives/Public/www-style/2014Oct/0188.html
(I'm somewhat disinclined, but Tab is gung-ho on this one.)
2. Resolve naming of automagic keyword for 'flex-basis'.
https://lists.w3.org/Archives/Public/www-style/2015Jan/0346.html
Input from implementer and usability perspectives welcome.
Other open issues include
3. Spec conflicts wrt handling page-break controls on flex items
https://lists.w3.org/Archives/Public/www-style/2015Jan/0349.html
Part of the spec forces a flex-line break at that point,
other part of spec propagates the page break to the flex line
in the case of row flexboxes. Not sure yet which is the
behavior to recommend, so if you have thoughts on applying
page break controls to flex layout, please help us figure this
one out.
4. Abspos issues
https://lists.w3.org/Archives/Public/www-style/2014Sep/0396.html
Tab and I haven't quite figured this one out yet. We suspect
there's an error in the spec. We'll report back once we know.
Issues I think we might want to defer to the next round of
publication, but are currently open for discussion
5. a11y, tabindexing, 'order', and other amusements as presented
by Bo Campbell; this one seems to need more discussion time.
6. Controls for flex line breaking; this one also needs more
discussion time, and is likely to end up deferred to a next
level of either css-flexbox or css-break."
flex-basis: magic
-----------------
Rossen: For the flex-basis one, we were going to implement the
'content' keyword, or value rather. It works pretty good,
we haven't heard any feedback about the value names.
Rossen: At this point we'd appreciate it if we would stop changing
our minds.
TabAtkins: Sounds fine to me.
Rossen: fantasai you have a concern here, are you okay?
fantasai: I don't mind. We didn't resolve on a name, we just had a
placeholder in the draft. It's just a matter of if it's
okay or if there are other words.
Rossen: We went with the 'content' value and we haven't heard
anyone being offended by this name.
TabAtkins: I'm find with 'content', if there's no objections let's
resolve and we'll lock it down.
plinss: Objections?
RESOLVED: Use 'content' as the new value for flex-basis
<tantek> Aside - plinss, I wasn't able to complete the edits for
CSS3-UI by yesterday (circumstances :( ). All issue
resolutions documented (even if just "refer to open
issue") on issue page. Editor's draft edits will be done
shortly today. R EQUES T: proceed with publication
(assuming group does not object, as agreed last week),
even if that means next publication week.
Adding a 'no-wrap' keyword that means the same as 'nowrap'
----------------------------------------------------------
<fantasai> https://lists.w3.org/Archives/Public/www-style/2014Oct/0188.html
TabAtkins: The first issue was a while ago about aliasing the
'nowrap' value to now have a dash. We had a dash
originally and removed it to match whitespace, but it's
hard to remember. On the other hand we can't remove
'nowrap' at this point.
TabAtkins: We should add an additional value of 'no-wrap' that
means the same thing as 'nowrap'.
Florian: I have no strong opinion as to if we should, but if we do
that's the right way to do it.
plinss: How will it serialize?
TabAtkins: They're two separate values, so they'll serialize as
you put it in.
Florian: For property we can do magic, but for a value this is
smarter.
plinss: Objections?
Florian: Just to clarify your proposal, this is to edit for
whitespace too?
TabAtkins: We can and should edit whitespace.
fantasai: I think it's ridiculous to do only one. I'd like to hear
from others.
gregwhitworth: We're running some queries. I think this would add
to the confusion. It's kind of a toss-up as to
what's the most confusing.
TabAtkins: Here's the tweet that mentioned the confusion.
<TabAtkins> https://twitter.com/SlexAxton/status/519953582183809024
TabAtkins: Once we get the 'no-wrap', we can deprecate 'nowrap'.
It'll be valid, but the spec won't recommend it because
it isn't normal naming rules.
<sanja> q+ is there any number on how many dash-including-values
we have?
tantek: Does this effect DOM serialization?
TabAtkins: No. They're two different values that do the same thing.
dbaron: Are they separate at specified value stage and value and
computed?
TabAtkins: No, because if we did at computed we'd have to go to
the stupid value of 'no-wrap'.
TabAtkins: If people believe we can get away with a rename good,
but I'm not sure we could. I'm being conservative and
saying the safe option.
tantek: I think we'll confuse web authors with them both existing
as possible serialization. If someone is looking for a
'no-wrap' they have to look for two different values. I
think it's complex. I'd be okay with parse time alias.
TabAtkins: They're impossible for values.
tantek: You say it computes to.
TabAtkins: That's not parse time. We can do that for properties
not values.
tantek: Pseudo Elements is similar to this. They were
grandfathered in like :first-letter. You don't get
:first-letter and ::first-letter.
TabAtkins: It's a compat call. If we can do that, let's, but if
it's not compatible.
fantasai: The pseudo elements is a parse time thing.
fantasai: The specified value would still be 'no-wrap' or 'nowrap'.
fantasai: Are you saying 'no-wrap' should parse in as 'nowrap'?
tantek: I'd be fine with that.
<Bert> (I don't like aliases, people will ask for 'colour' again,
but we do have already an equality between .123 and 0.123,
and between 10mm and 1cm...)
tantek: If authors are putting in 'no-wrap' and expecting it to
work, I think that would be the easiest fix.
fantasai: I agree with you.
TabAtkins: Theoretical stumble points aren't this, this is a real
stumble point. It's a confusing inconsistency with the
language. We can say there may be future confusion, but
we know there's current confusion.
tantek: That's why I said it's okay to alias at parse.
plinss: Anyone writing script will have to look for the undashed
value.
tantek: They'll have to look for both in the future. You can make
them look for two or one. That's the choice.
plinss: If they're writing code against themselves they can look
for their own style.
tantek: Their own style sheet in this age of corporations is
becoming increasingly rare, we can see that as an
architectural sticking point.
* fantasai tantek++
fantasai: Even if you are, you can accidentally do one or the
other over time. Or we don't make you do that.
gregwhitworth: Do we know of anyone checking for 'nowrap'?
TabAtkins: I don't know and don't know how we'd check. It would be
difficult. That's why I suggested the conservative.
Rossen: Will you implement for only unprefixed, or would you push
that to prefixed webkit?
TabAtkins: The conservative isn't a compat issue, so there's no
reason to hide it behind only the unprefixed.
Rossen: If we all change it at the same time so that we will
effectively force people to start using the dashed version.
fantasai: We'd have to be consistent and if we do undashed in one
and not the other it's worse. whitespace has been around
since CSS1.
TabAtkins: Removing 'nowrap' wasn't on the table.
Florian: What's confusing is merging into one.
<tantek> I'd like to see "no-wrap" work at *parse* time as a
minimum, and I see the use case for that.
<tantek> you can also access it as a property right?
element.style.nowrap currently
<tantek> does it become element.style.noWrap ?
<tantek> are they aliases?
<tantek> or sorry - element.style.whiteSpace = "nowrap"
<tantek> or element.style.whiteSpace = "no-wrap" ?
TabAtkins: I'm finding code that checks for 'nowrap' in JS.
TabAtkins: So it's probably a thing that happens.
plinss: So alias at parse time, two values, no change.
TabAtkins: There's no alias at parse. We can do computer time into
legacy 'nowrap' keyword.
Rossen: But then it sucks. For completeness let's have it, but
it's not a good option.
<fantasai> Options:
<fantasai> A) Parse no-wrap as nowrap
<fantasai> B) Treat as two keywords with identical definitions
<fantasai> C) no-wrap computes to nowrap
<fantasai> D) Do nothing
fantasai: The options are in IRC [reads the options]
<TabAtkins> (A) is not an option.
fantasai: A is an option because tantek brought it up.
TabAtkins: It's not because parse time isn't a thing we can deal
with here.
<dbaron> TabAtkins: ... variables
TabAtkins: It's just not an option that accomplishes what we want.
fantasai: It will deal with the dash for most authors.
plinss: So it's an option, but not one you like.
plinss: I'm not hearing consensus. Maybe an IRC straw poll?
plinss: Type your choice, A, B, C or D.
<TabAtkins> B
<sanja> C
<fantasai> D or A
<Florian> B
<Rossen> D
<dbaron> D
<tantek> A, ok with C or D.
<glazou> abstain
<gregwhitworth> D
<antonp> abstain
<astearns> B or D
<smfr> D
<Bert> D, then A
<dauwhe> abstain
<koji> B
<Rossen> D
<adenilson> abstain.
<SteveZ_> D, because I am not convinced that the solution is an
improvement
<murakami> D
<fantasai> Just to clarify, this affects both flex-wrap and
white-space properties
plinss: It seems the clear winner is no change.
plinss: Anyone that can't live with it?
TabAtkins: I'm unhappy because I think people with no webdev
experience aren't experiencing the pain.
Rossen: I think this isn't a never change, we should keep working
on it.
TabAtkins: There's no other options!
Rossen: So it seems we should approach this otherwise.
tantek: I think implementors could support A and if there's
implementation consensus on that we adopt it.
fantasai: We generally discourage people doing tag soup parsing of
their own. We did that in the 90s.
fantasai: It ended poorly
plinss: I'm seeing most people saying do nothing, but lots of
people wanting to keep talking about this.
Rossen: One more thing before we finish this, why are you pushing
to change both of these? I see changing flexbox and we can
do that regardless of whitespace.
TabAtkins: Reason we're not doing that is consistency in the
language is more important than theoretical consistency.
TabAtkins: They need to be either all changed or none changed.
Rossen: I'm not convinced with that.
plinss: Let's move on. If someone can get better data for the F2F
that would be welcome.
plinss: Next issue.
Remaining Flexbox Issues
------------------------
TabAtkins: Next was the naming issue we dealt with before. After
that is allowing specifying when wrapping should happen.
TabAtkins: Right now in Flexbox 2 we want to let people do flex
breaks to get wrapping the way they want.
fantasai: I think that control of flex wrapping needs a lot more
discussion since we don't have exact issues.
fantasai: There's also abspos where we don't understand. There's
the page breaking controls which also isn't worth
discussing since we don't have a sense of pros and cons.
fantasai: So I think we're done for flexbox.
gregwhitworth: Can you keep us in the loop on the abspos issue.
fantasai: We don't understand the issue yet, so if you do please
post and tell us what to do.
gregwhitworth: I don't know, but I'm intrigued to see what you
guys find.
plinss: Are you expecting to have this for the F2F?
fantasai: Should.
<astearns> let's get the flex break issue on the ftf agenda
Rossen: Is that the same issue we did when you were visiting?
fantasai: That was a different one.
extending break-* to lineboxes
==============================
fantasai: This was an idea, the break controls are useful for
fragmentation controls. Do we want to extend that for
linebreaking?
fantasai: Let's say I don't want my links broken across lines,
they won't break unless the line is too narrow and then
it will break.
fantasai: We've talked about forced break controls about breaking
before and after. Break-inside, I've wanted for a while
and its showed up in various drafts. We could adopt
these two wholesale for linebreaking.
fantasai: break-inside: avoid (for example above)
<dbaron> seems like interactions with 'white-space' could be
interesting, though maybe not. At the very least
confusing to have both...
tantek: Conceptually, I wonder if there's a possibility where you
say you don't want it to break unless it won't fit. Maybe
there's also a case where you don't want it to break, but
you want it to ellipse.
fantasai: You can do that with display-inline-block.
tantek: You need a width and you can't set that.
fantasai: You do max-width: 100%.
tantek: That's a lot more complex and you have baseline alignment.
fantasai: They work by default.
<fantasai> element { display: inline-block; max-width: 100%;
overflow: hidden; text-overflow: ellipsis; }
tantek: With inline block?
fantasai: Yep.
plinss: So you don't want a resolution, you just want to introduce
this?
fantasai: Yes. We should move on.
<tantek> thanks fantasai - that's interesting, might have to try
that
<tantek> worth mentioning as an option
Florian: Do we have a content problem where previously it did
nothing and now does something?
fantasai: Seems unlikely. The break properties are relatively new.
Florian: Fair enough.
text-wrap: balance
===================
plinss: astearns?
fantasai: I can do it.
<astearns> sorry, was muted
<fantasai> http://dev.w3.org/csswg/css-text-4/
fantasai: There's been discussion about balancing lines or text so
they're approximately even.
fantasai: astearns and I drafted a proposal that could change a
lot as we discuss. We want to do CSS4 Text at the F2F.
We did a ED for CSS4 Text.
fantasai: We put that in and a couple of things that were cut from
level 3.
fantasai: We invite feedback on all of that and at some point we'd
like it to be official. I don't know if astearns had
anything else?
Bert: Are we discussing balance now?
fantasai: Sure.
Bert: I think balance is only useful for center aligned. Left and
right should use indent. It's two things in different
context and balance isn't an explicit keyword.
astearns: It's useful with centered. You'd want it on left-align
headlines. It's a different operation than getting the
last line length you want. With headlines you can get
short then average when you're trying to extend the last
line length you tend not to want very short lines
Bert: Another interaction is automatic font size. I'd like the
font size to include the ability to fill the last line.
astearns: I would call that content fitting. In addition to font,
you may want other properties. I'm interested in that,
but I think it's separate.
plinss: Agree, but we do have to worry about interaction.
plinss: Anything else on this?
Florian: I've mentioned my thoughts on the mailing list.
CSS3 UI
=======
Negative Values for Line Offsets
--------------------------------
tantek: There's a bunch. I'd like to...I put in IRC I was able to
go through the outstanding issues enough that I could put
it in the draft. Sometimes we mention the issue inline.
Some things we have resolutions or Florian and I agree on
or are close on.
tantek: First one is one we've discussed previously.
tantek: I think it's number 38 which is negative values on line
offsets. Since it's got inconsistent support, it's at risk.
Florian: One difference between our versions, how you deal with it
if you do it we agree, but you have that browsers don't
have to support negative values. I'm not sure I'd have
that since everyone that supports does support negative.
tantek: I think I put that before the at risk bit. As long as it's
at risk if we decide no one is interoperable we can fall
back to negative values aren't supported.
Florian: Everyone does it, they just do it differently
tantek: But we can't spec that. So we can go to CR if that doesn't
get resolved.
tantek: Other opinions? Other implementors want to chime in?
fantasai: A link would be helpful
<fantasai> http://dev.w3.org/csswg/css-ui/#outline-offset
<tantek> https://www.w3.org/wiki/CSS3-UI#Issue_38
tantek: That's the draft and the issue
Florian: The idea is once you're negative, you're allowed to be
negative, but you have to stop before the small box in
the middle is smaller than twice the width.
tantek: That's from our previous discussion. It's not new.
Florian: That's the proposal I made on the list.
tantek: We discussed it on the telecon with no objections. Unless
there's new information we should go with that.
fantasai: I'm confused as to why twice the outline width instead
of 0.
tantek: So there's something that can be rendered. It shouldn't
override the outline width or style.
fantasai: ooooh. I was imaging interior size not exterior. I think
you should clarify that.
Florian: So you disagree on phrasing, not behavior.
fantasai: Yeah.
tantek: Okay. We can accept that.
plinss: Maybe even a diagram would be useful
fantasai: Did we decide if negative are optional, at risk, or both?
tantek: The intent was at risk. That's what we're proposing. The
optional bit was before that.
Florian: We want it this way, but we're worried about
implementations. The other option is to replace the must
with a should.
fantasai: That seems reasonable to me.
tantek: I'll turn it into a should and take out the may ignore.
plinss: Objections?
RESOLVED: Change the must into a should and remove the reference
to "may ignore"
<smfr> behavior on non-rectangular shapes needs to be specified
<smfr> don’t assume the outline is rectangular
ime-mode property
-----------------
<fantasai> file:///home/fantasai/w3c/csswg/css-ui/Overview.html#input-method-editor
<fantasai> http://dev.w3.org/csswg/css-ui/#input-method-editor
tantek: The basic summary is ime-mode isn't well designed and we
don't think it should be implemented. What I've edited is
to obsolete ime-mode
tantek: To say implementors should drop support ASAP. Authors must
not use it and users may use a certain hack to fix past
misuse. This is proposed instead of completely dropping
since I don't think that captures that it's a bad idea.
tantek: That's what we've written there.
fantasai: I've read it and it makes a lot of sense.
dbaron: I'm not convinced it's a bad idea.
Florian: The Mozilla implementor said it was.
Florian: It's not doable on mobile and editing type on mobile is
though a virtual keyboard. Basically if you're thinking
of a desktop running windows for an audience in Japan it
works, but if you break that it doesn't.
dbaron: We probably need something to replace it.
Florian: There are things moving in the right direction.
<fantasai> +1 to what Florian said
Florian: There are things in HTML hinting at what type of thing
you expect to be input and the UI can display the most
reasonable input. There are missing values, but I'm quite
convinced that ime-mode is a bad idea.
tantek: Any other thoughts on obsoleting ime-mode?
fantasai: I'm 100% in favor.
Florian: The text you have now mentioned it's obsolete elsewhere?
tantek: As a reference for incompatibility.
Florian: Yeah. Okay.
plinss: Do we need a resolution?
fantasai: I think we do. Document ime-mode as obsolete as
described in the draft?
plinss: Objections?
RESOLVED: Document ime-mode as obsolete as described in the draft
SteveZ: I think your link to a non-normative should be IDed as
non-normative so it's not a problem.
plinss: Just change to a note.
SteveZ: If it's not in a note, it's normative if it's in a
normative section.
tantek: I'll start with a note to make it more clear.
dbaron: I'm not happy about the precedent set by saying
implementors that don't have the property shouldn't add it
and if implementors have it they should drop. I'd rather
consistent across all implementations.
tantek: Are you arguing for stronger language?
dbaron: I think it would make more sense as a should not for
everybody.
tantek: Should not support?
dbaron: ummhum.
tantek: I'm fine with that. Florian?
Florian: I'm fine with that. It means IE won't pass the test suite.
Rossen: IE will have to chat with the editing folks and come back.
I can't comment at the moment. But the previous would have
been more favorable because it gives us an out. Dropping
it since we have it is a question for us and I don't think
we'll do it.
Florian: I expect that IE will keep this for quite a while. People
using IE on a desktop isn't that rare. I think it's fine
to drop with the understanding it's unlikely to happen
with IE.
plinss: Anything else on this one?
tantek: I've made the changed from dbaron so I'll regenerate.
Rossen: So you're changing to a strong should not?
tantek: I'm making it "should not support".
Rossen: Yeah. Okay
Rossen: That's a favorable spec for someone who won't support.
We'll most likely be non-compliant.
plinss: That's the top of the hour. I'll see most of you in Sydney
in two weeks!
Publication (after call)
-------------------------
tantek: About the publication, clilly asked me to put everything
together and I'd like to publish.
Rossen: If we don't have a resolution on the previous issue we
should wait. We said obsolete, but we didn't resolve on
the should not.
Rossen: If you want to publish that's fine with the t-1 version.
Otherwise we should discuss further.
tantek: I'm okay with that if dbaron is okay with the change
coming in later.
tantek: I'll add the 'should not' to the ED after the publication.
plinss: Do we need a resolution?
tantek: We resolved to change and publish last week. I'm hoping
the past stands.
Rossen: I'm fine with the last, I'm not happy with the
not-resolved additions. Publish with everything resolved
and we'll discuss more once the draft was out.
plinss: Let's go ahead and publish.
tantek: I'll point to last week's resolution.
Received on Thursday, 29 January 2015 01:23:37 UTC