- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 7 May 2014 20:29:03 -0400
- To: www-style@w3.org
Grid Update/Publication
-----------------------
- RESOLVED: Publish an update WD for Grid
Whitespace in calc()
-------------------
- There was basic agreement that when dealing with + the added
whitespace wasn't needed, but there were concerns about -
being confused with keywords.
- There was agreement that the priority should be author
readability/usability not tokenization.
- TabAtkins will outline the exact proposal on the mailing list to
solicit feedback with a goal of doing a poll of the working
group on the next call (14 May)
Publish WD of GCPM
------------------
- RESOLVED: Publish updated WD of GCPM
- The new WD will maintain references to the items that were
removed and what specs those items landed in.
:modal Pseudo-Class
-------------------
- RESOLVED: Add :modal to selectors level 4
- There was some concern that a pseudo-class wasn't the best way
to address modal, but not enough to block a resolution.
- A few members of the group expressed an interest in eventually
investigating and potentially creating a pseudo-class to
query properties.
Flexbox
-------
- The editors asked for anyone with comments to submit them ASAP
so that they can publish a new LC next week in order to
garner input on the two different algorithms for resolving
lengths.
Seoul F2F
---------
- Everyone was again reminded to add discussion topics to the wiki.
Line Layout
-----------
- RESOLVED: Add fantasai and dauwhe as editors to line layout
====FULL MINUTES BELOW======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Dave Cramer
Elika Etemad
Sylvain Galineau
Daniel Glazman
Dael Jackson
Brian Kardell
Taichi Kawabata
Brad Kemper
Peter Linss
Michael Miller
Shinyu Murakami
Edward O'Connor
Simon Pieters
Simon Sapin
Dirk Schulze
Alan Stearns
Lea Verou
Greg Whitworth
Steve Zilles
Regrets:
Anton Prowse
ScribeNick: dael
Grid Update/Publication
-----------------------
plinss: Let's get started
plinss: We have a short agenda. I saw the Flexbox addition from
fantasai Anything beyond that?
fantasai: I'd like to say that it would be good to publish grid
next week.
fantasai: I don't think there's significant changes, mainly just
the algorithm. Does anyone want more changes?
plinss: Just an update?
fantasai: Yeah. Mainly it was fixing random bugs and the algorithm
update.
Rossen_: I'll take a look and give feedback
fantasai: I'll try and create a formal comments list. It's mainly
issues from SimonSapin
plinss: Do folks want more time, or are we ready to publish an
update?
plinss: Anyone?
plinss: So we're okay with publish an update? Any objections?
RESOLVED: Publish an update WD for Grid
SimonSapin: No objections but I sent some issues about grid to the
mailing list.
fantasai: I'll scan through and fix those or mark them as issues.
SimonSapin: Okay
Whitespace in calc()
-------------------
<Rossen_> http://lists.w3.org/Archives/Public/www-style/2014Apr/0480.html
TabAtkins: I talked about this more with zcorpan and I'm okay with
making the grammar more complex to make it simpler for
authors.
TabAtkins: I can at least make it so you can use + without the
extra spaces
TabAtkins: I can't figure out using - without killing keywords in
the future.
<TabAtkins> calc(auto-2em)
TabAtkins: In particular I don't know how we'll get the above
example to work.
SimonSapin: I think it's fine if that particular case doesn't work.
<TabAtkins> calc(1em-2em)
TabAtkins: I'm not okay with that. If that (above) works I don't
know why a keyword wouldn't. I hate rules where you
need spaces with a keyword but else wise not. It's not
great to add spaces, but at least it's only one rule
they have to remember.
<astearns> +1 for more consistent (if more limited) rules
TabAtkins: So I still don't know what to do about this.
TabAtkins: Is zcorpan on the call?
plinss: I don't think so.
TabAtkins: So I guess I have to keep talking to him about this.
I'm not sure what he thinks about that case and it's
not clear from his notes.
TabAtkins: Okay. So I'll keep talking to zcorpan.
plinss: Anyone else with ideas/thoughts?
* fantasai agrees with astearns and dbaron
SimonSapin: What if we remove the whitespace restriction, but we
don't change ident. rules. So in your example it would
be required but not if it's unique.
<TabAtkins> calc(1-2)
TabAtkins: So in other words calc (1px - 2px) would work?
SimonSapin: Yes.
glazou: I'd like to comment on my message. It seems like we're
only looking at tokenization, not readability.
glazou: The message from web authors is they don't care about
tokenization so if we only care about that we make
confusion.
TabAtkins: This isn't just tokenization. Simplest to tokenize is
using whitespace everywhere and I'm willing to change
for readability, but there's one case that's
intrinsically impossible, as far as I can tell.
TabAtkins: Else wise I'm fine with technical grammar being harder
to make it easier for authors.
<TabAtkins> calc(1em+2px)
TabAtkins: I'm fine that it's complex enough that the above works.
TabAtkins: That's not valid today, but I'm fine making that valid
tomorrow.
glazou: I'm okay with that too.
dbaron: Are you okay with making that work but -2px doesn't work?
glazou: I want both.
TabAtkins: There's an intrinsic issue.
glazou: I want this to work on readability size.
TabAtkins: Burdens on our side are insurmountable.
glazou: I want this to work. It's implementation issue, not a
blocker.
<TabAtkins> calc(auto-min-content)
TabAtkins: This is a blocker. There's no way to pull above apart
into subtraction of two keywords.
TabAtkins: We can do it in our brain, but not in implementation.
glazou: If +1px works and -1px doesn't, people won't know why.
TabAtkins: I agree. That's why I hesitate to change + because then
- doesn't make sense.
plinss: So maybe we need to think about making - work.
plinss: If we're parsing keywords in calc() with - you would stop
at shortest known keyword when you get a -.
TabAtkins: That makes tokenization context dependent.
plinss: It's ugly but could work.
SimonSapin: So that's a reasonable definition of changing the style
<TabAtkins> calc(1px-2em)
TabAtkins: So you say allow the above because units can't have -,
but keywords can. I'm somewhat against that because
it's easy to trip over.
SimonSapin: I agree, but is it worse than what we have now?
TabAtkins: I don't know. Maybe?
glazou: I don't think so.
<astearns> if we had keywords 'foo' and 'foo-bar', you would not
be able to use 'foo-bar'
<TabAtkins> astearns: Good point.
glazou: I think anything that increases intuitiveness on the
author side is good. We have too many complaints about CSS
getting complex with syntax and everything we can remove
is good.
TabAtkins: I agree, but there's a problem we can't solve and until
we don't have that problem I'm probably not comfortable
with making these changes.
TabAtkins: I could be convinced about +, but I'm not sure.
TabAtkins: I suggest we make no change for now and continue to
discuss how to get around the keyword issues, since we
know keywords will work in calc() eventually.
<fantasai> Consistency is a tool for navigating complexity.
<fantasai> We shouldn't break consistency in some cases but not
others, that introduces more complication.
SimonSapin: I still think the original proposal is the best.
TabAtkins: That's the one that requires space with keyword, but
else wise allows you to remove them.
SimonSapin: Yes.
TabAtkins: So it requires space when sub keyword from something.
SimonSapin: Anywhere that you have a - that could be interpreted
as a sign, but we only have a few properties where it
happens. Where you need a + sign is okay.
TabAtkins: The reason we don't have a problem is that it's
traditional to add a space. People do it with binary
math. The tokenization already exists, but no one hit
it before.
SimonSapin: People are used to inserting whitespace before a
keyword.
TabAtkins: No, they're not used to inserting between operator and
arguments because they don't do it elsewhere. But
because - is in as a valid namespace you have to in CSS.
SimonSapin: Maybe.
TabAtkins: That said, I could go with that if the rest of the WG
goes with it. It's a nice win overall so it might be
worthwhile.
TabAtkins: I suppose we could poll.
glazou: I'm willing to review.
<bkardell_> can we see an example?
TabAtkins: How about I outline the exact proposal in the ML, get
feedback, and we poll in the next call and I'll accept
the WG's decision.
glazou: Fine with me
plinss: Sounds like a plan.
Publish WD of GCPM
------------------
dauwhe: Previous draft is from Nov 2011 and now there's a new
editor and much has been moved to other specs
dauwhe: What's left is based on the WG resolution in Paris so I
think it's time for an up to date WD.
dauwhe: An implementor has joined the WG so I think we can make
progress.
plinss: Sounds good. Any objections?
<fantasai> +1 for publishing
<glazou> +1 for publishing
Bert: So the parts not in GCPM, are they somewhere?
Bert: I agree they don't belong, but they should be somewhere.
dauwhe: I've made notes in the ED about changes from the last
version. I could easily add something saying where the
pieces ended up, some to Page, etc.
dauwhe: Would that address it?
bert: I see changes have some notes, maybe it should have a bit
more.
bert: Otherwise I think you can publish, yes.
dauwhe: Instead of just saying something was removed, I can say
where it ended up. That's easy.
fantasai: One thing I would recommend is keep the section headings
in for what was removed and add a note.
fantasai: So people using the links land on the note.
dauwhe: I can do that.
fantasai: If anything that moved hasn't been publish as an updated
WD we should do that, too.
dauwhe: I'll look through that. I'll have to see about maintaining
anchors to links and I think the structure is somewhat
different.
fantasai: Just make sure links don't break. When I split Text I
have a bunch of anchor tags that got to a note saying it
had moved.
fantasai: Eventually you can remove the headings and have a note
for all of it.
dauwhe: I'll look at your examples. Sounds good.
plinss: Are we okay to resolve with those changes, or does anyone
want to review? Any objections?
RESOLVED: Publish updated WD of GCPM
plinss: dauwhe you've been writing tests?
dauwhe: Yes, I have quite a few.
dauwhe: I need to check to make sure it's covered.
plinss: I don't see them in shepherd.
dauwhe: I uploaded a bunch during TTWF, but I'm not sure what
happened in that process. I'll look into it.
plinss: Ping me off line if you need help.
dauwhe: Okay. Thanks.
:modal Pseudo-Class
-------------------
TabAtkins: That was me
TabAtkins: Hixie has been working on modal dialog and the dialog
element can be modal or non-modal and it depend on how
you call it.
TabAtkins: There's not a CSS detectable way to tell if it was
displayed as modal, but you clearly want to style
differently.
TabAtkins: The suggestion is to add a pseudo-class to detect. The
suggested name is :modal
glazou: How do you make the difference in the dialog?
TabAtkins: Dialog has .show and .show-modal
glazou: It's unfortunate it's not an attribute.
TabAtkins: It makes sense to display depending on circumstances.
For example you'd want to display normally usually, but
once in a while you want modal
Bert: Doesn't it make sense to have it display.modal since you'd
need to re-display?
TabAtkins: Not really. A modal dialog may want to be styled in
more attention getting ways. There's not particular
ways out there where things want to be different.
bert: So let's say I want to use JS and have some difs so I want
it to display correctly.
TabAtkins: Correct, you need JS.
bert: So you need a property for that. You don't need a selector
anymore.
TabAtkins: You can do what you need for display. You don't need a
new property.
bert: We don't have pop-ups. We have position, but that's in the
same window. Nothing says this is new.
TabAtkins: Right, dialog is in new windows. That's another thing
we're letting happen in the web.
plinss: I agree we need a property, but this is a question of the
behavior, not the display. The behavior could be either,
but the modal can only be invoked through script.
glazou: I'm not convinced we need two methods, I think I'd prefer
an attribute, but I won't object.
TabAtkins: You know that's been exposed, like do we do modal
attribute, but because there are cases where you want
to display as either, methods seemed more intuitive.
glazou: You'll need something on dialog saying if it's modal or not
glazou: It'll have to be somewhere so why not an attribute? At
some point you'll need one, so I don't absolutely see need
for a new pseudo-class
TabAtkins: What do you mean?
glazou: When you do dialog that can be open modal or not than you
want to know how it was open so you need and attribute.
TabAtkins: No you need a property.
glazou: I was mentioning attribute on an interface
TabAtkins: You can't access JS except through a pseudo-class
<bradk> Why not 'display: dialog-modal?'
plinss: The other alternative would be that we had a generic
pseudo-class to let you query property.
TabAtkins: A lot of properties have values that aren't
strings/numbers and we couldn't do anything generically
with them in CSS
TabAtkins: We can do number or boolean, but not date.
glazou: Date can be two strings.
TabAtkins: But you can't query that usefully, but you can do that
with past and future pseudo in queues.
TabAtkins: So a lot of things can't be used generically. I'm not
opposed to doing that as well, but it would need future
thought.
<leaverou> btw one problem with :modal is that it applies to the
dialog only, so doesn't help with e.g. adding an
overlay (unless one adds it as a pseudo-element on the
dialog but that's tricky)
zcorpan: I think it seems scary to be able to select based on a
property because that property can have a side effect.
TabAtkins: Oh. That is true. In that case I don't want to get into
that can of worms without a lot more thought.
plinss: We don't want to just throw it in there, but it's worth
exploring. Perhaps just as a note in a future level of
selectors.
plinss: Short term :modal may be way to go.
TabAtkins: And I'm fine with adding a note that we'd like to
explore generic property access.
TabAtkins: So any objection to adding :modal or better names than
modal?
Bert: I'd like to see a comparison to other things we might add
like stretch text and tool tips.
bert: I'd like to see a framework for all of those, not just add
one and deal with the others later. Think of all the ways
display might happen.
glazou: I have a related inquiry. Modality can be dependent, a sub
dialog, etc. Do you expect a pseudo for all these?
TabAtkins: Dialog is on top of everything is already going on so
it would be a property. We've discussed this
internally, I just need to propose it.
TabAtkins: Slaving an element or something will happen at the
property.
TabAtkins: That doesn't happen with modal because it's a strange
interaction that can be flipped on or off.
TabAtkins: More importantly you want to style differently and if
modal is a property you can't do different.
zcorpan: Modal is top layer.
TabAtkins: That's something we anticipate baking into CSS, but
it's not a magic switch, just a new value or property
added to positioning
TabAtkins: Basically, other aspects of dialogs that are magical
will be done through styling, but if you're modal you
want to base styling on that which is why we're asking
to add it to selectors.
plinss: So back to the question, any objections?
TabAtkins: What I said also addresses Bert's comment. Other things
like tool tips aren't what you want to be selecting on.
TabAtkins: So back to any objections?
plinss: Not hearing objections. Is this going into 3 or 4?
TabAtkins: 4. Or did you mean between 4 and 5?
plinss: Yes.
TabAtkins: Given that it's being implemented now I think 4 is okay
but if people object to that, I'm okay with 5.
TabAtkins: This is something people want to expose in their
implementation.
RESOLVED: Add :modal to selectors level 4
Flexbox
-------
plinss: There's an open issue in the DoC?
TabAtkins: You want to handle that fantasai?
<fantasai> http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325
fantasai: Here's the issues list (above)
fantasai: I think Rossen_ sent a comment that we need to add to
the list.
Rossen_: I have one more, too.
fantasai: This is everything filed since last call. That one
that's open is alternate wording for length.
fantasai: So, before it was discontinuous between 0 and non-0 and
we made a change and published the LC. However when
TabAtkins made the change he shipped based on the
concept of desired size
fantasai: Rather than operating on flex values and normalizing
them and once normal doing the multiplication.
fantasai: That's a shift from the CR text but in implementation
it's better dealing with rounding because you have a
constrained range.
<fantasai> http://dev.w3.org/csswg/css-flexbox/#resolve-flexible-lengths
fantasai: Both are in spec with all the various bug fixes. We
folded bug fixes into both options.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014May/0028.html
fantasai: Question is what's easier to read and did you notice any
difference in results since that would indicates a bug?
fantasai: We'd like review and don't want to CR today, but we
likely need a 2nd LC since there were a bunch of
normative changes to fix bugs.
fantasai: There's the issue from Rossen_ right now and that's it
for DoC.
TabAtkins: So I think we're asking for LC with both algorithms and
implementors will give us input on which to keep. We'll
ask for CR after the next F2F.
fantasai: If anyone is holding off on issues, we'd like to address
those as well.
krit: If this is feedback from all browsers, it sounds reasonable.
plinss: So to be clear, you're asking for LC?
fantasai: I'm asking if anyone has issues they haven't filed.
TabAtkins: Except Rossen_'s.
Rossen_: I'm filing it now.
fantasai: Anyone expecting issues?
Rossen_: Maybe. We haven't found anything jarring so I'm not
expecting any major delay, but I'm not willing to say no
issues.
fantasai: So I suggest we publish LC next week on Tues or Thurs
and that will be a short LC since the things that have
changed are all in this one page section.
TabAtkins: So I suggest Thursday with a resolution on the next
telecon.
plinss: So you want to hold off on recording the resolution till
next week?
TabAtkins: Yes. If there are any issues, please record them ASAP
so we can address before next week.
TabAtkins: For a few more days we can address things with alacrity.
Seoul F2F
---------
plinss: Okay. That's the end of the agenda.
plinss: F2F is coming quick, so please add topics. I know we get a
flurry of comments at the end, but sooner would be better.
Line Layout
-----------
fantasai: I have a question
fantasai: Since we were working on baseline I was thinking of
taking a pass on line-layout.
fantasai: Does anyone have concerns about me editing?
SimonSapin: I have comments, but no concerns.
SteveZ: I don't have any concerns. I didn't e-mail.
fantasai: Okay. I'll look it over. I'm not going to address
issues, I'm just going to clean up.
fantasai: I'll bring it more into alignment.
dauwhe: I'm interested in the initial caps area.
fantasai: I'll be mostly ignoring that.
SteveZ: I would be too. I don't think it belongs.
dauwhe: There's a lot of interesting in that in publishing since
current is horrible.
SteveZ: It involves problems of aspect ratio.
dauwhe: And authors knowing height of a particular cap.
SteveZ: Often you'll want to align to the form underneath and
maybe with line grid it would be easier.
dauwhe: Is there a natural way to have it fall out of grid, or
does it need to be separate?
SteveZ: I think separate. Main problem was you wanted to position
baseline of initial cap and set distances so it covered
even number of lines.
dauwhe: Yes, there was a desire to get initial value of the cap
lined up in advance.
SteveZ: Body height and face height can be different for different
fonts and that would affect appearance.
TabAtkins: Sounds like something that can be automated with line
grid.
dauwhe: I think I can get interest from implementors on this
subject. People at iBooks are interested.
sgalineau: As you know we've been playing with text flowing around
a big cap. Seeing the author-facing notes would be very
useful.
SteveZ: Since you want to do drop caps and fantasai doesn't, does
it make sense to split it?
fantasai: I'm not sure where it goes best, but we can co-edit.
<fantasai> don't have to split the spec in order to both work on
parts of it :)
dauwhe: I was thinking I could do a rough-cut and get what's there
to a point where it's easier to discuss.
plinss: So dauwhe are you willing to be a co-editor?
dauwhe: Yes. As long as I don't have to be expert on everything.
TabAtkins: It's not like any of us are.
dauwhe: Everything I've seen with this group leads me to believe
otherwise.
plinss: So any objections to fantasai and dauwhe being added as
editors to line layout?
SteveZ: I assume I'm still there.
TabAtkins: Yes.
SteveZ: I think John dropped off
krit: He doesn't reply to e-mails.
* sgalineau will keep working on dropcaps until someone considers
them harmful
RESOLVED: Add fantasai and dauwhe as editors to line layout
plinss: Should someone ping John to see if he wants to stay?
SteveZ: Well he can't because he dropped from the group.
plinss: Okay, he'll be a former editor.
SteveZ: I think the process requires editors to be in the group.
plinss: I guess that's it. Thanks everyone.
dbaron: I won't be around next week.
glazou: I have one more thing. Technically John Daggett is still
in the WG.
SteveZ: I thought he resigned
glazou: We left daily work, but the Mozilla rep, dbaron, never
removed him.
glazou: So he's a member.
SteveZ: Okay. So he can stay editor
SteveZ: dbaron, would you find out if John wants to stay?
dbaron: I can ask.
plinss: Thanks everyone. We'll talk next week.
Received on Thursday, 8 May 2014 00:29:38 UTC