- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Jun 2014 09:02:23 -0400
- To: www-style@w3.org
Flexbox
-------
- The unclear language in CSS2.1 for handling static positioning
was discussed with the leaning to further clarify relevant
details in the Flexbox spec.
- fantasai and TabAtkins will get usage data and draft a concrete
proposal on how to make flex-basis: auto less confusing,
potentially with a re-name.
- RESOLVED: Publish Flex CR with the CR version of flex
distribution algorithm.
- Flexbox also needs more tests before it can go to PR.
CSSOM and CSSOM View
--------------------
- Serialization and loading style sheets were the two main pieces
of CSSOM that were considered broken and a few potential
solutions to each were offered.
- For CSSOM View cases where the viewport is smaller than the
canvas was the first issue with different browsers handling
the case differently. Zcorpan will write out a proposal.
- The GeometryUtils API was mentioned with zcorpan planning to
look at the version Firefox shipped and work from there.
- Sub-pixel position raised a lot of concerns and some
implementors shared difficulties they've faced in trying to
implement it.
==== FULL MINUTES BELOW ======
Full Agenda: http://wiki.csswg.org/planning/seoul-2014#agenda
Scribe: dael
Flexbox
-------
plinss: Let's resume. I see you're queuing up for CSSOM?
plinss: So we want to wait for Chris? Okay.
plinss: Selectors 4?
TabAtkins: We were doing flex last night and couldn't finish
Selectors
plinss: We'll defer that to tomorrow
plinss: Flexbox.
<astearns> http://dev.w3.org/csswg/css-flexbox/
fantasai: There was a handful of editorial issues and there was
the 'flex-basis: auto' issue.
TabAtkins: When we were editing last night we can across a few
issues. We were talking about static position and 2.1
is incoherent.
TabAtkins: It only defines left, right and top. And left or right
are ignored, depending on if you're LTR or RTL.
TabAtkins: CSS2.1 talks about it if you're a box where only sides.
fantasai: This is editorial, but we can't rewrite without assuming
that static position is being redefined.
fantasai: I wanted to mention it as an issue. As far as normative,
the old and new wording are equivalent in terms or
results, it's just a difference of conceptualization.
fantasai: If there's a strong option from anyone but Rossen let us
know.
dbaron: I might have an opinion.
TabAtkins: Okay. What do we do about def of staticpos? Everyone thinks
of it as a point.
fantasai: I don't.
TabAtkins: I learned it in web dev as a point. Is this errata or
position?
fantasai: I don't think we need to redo 2.1. It's awkward,
but it's not wrong.
fantasai: I don't know what we want to do, but we should do what
we can in the CSS3 Positioning module.
fantasai: dbaron any opinion?
fantasai: On how to conceptualize style notation?
dbaron: If you want to do centering it's easier to redefine as a
point. You have to do it somehow, because right now if
it's a box and than you choose an edge you already have to
turn it into something else to do centering.
plinss: I have the counter concern that going back to footnotes
where we have a placeholder, why wouldn't that apply to
statics and fixed and it could be a box and just usually 0
size?
TabAtkins: I can't be. Tables mess everything up.
TabAtkins: I tried to say a place holder is 0 by 0 box where the
abspos is and that just wasn't possible. It's
inconsistent with flex and it didn't work for tables at
the time.
TabAtkins: Tables without content have a different staticpos than
would have been given.
fantasai: Staticpos in 2.1 is a set of four offsets, the fourth of
which they forgot to define.
dbaron: In theory you want that for vertical writing modes, but
you want the definition that's appropriate for the writing
mode.
fantasai: You need both dimensions and we have bottom to top.
dbaron: Except you use what we have for left or right, not the
missing bottom.
dbaron: Unless there's a mismatch between the abspos container and
the containing block.
TabAtkins: So we'll at least pursue the position. I'd like to make
2.1 not wrong
fantasai: It's not wrong; it just doesn't match how you think about it.
dbaron: I don't think there's a need to change 2.1 but I don't
know if the position spec is ready to be referenced in the
place of 2.1.
TabAtkins: It's not and that's my main problem.
fantasai: I don't think we need to change 2.1, I think we just
need to be clear about how we handle it. The wording in
the Flexbox spec is unambiguous.
Rossen: If position 3 is handled in grid, we'll likely do that in
the future.
fantasai: But for now if we're clear in flexbox that's good.
TabAtkins: The gregwhitworth thing we did last night. More
intrinsic ratios being confusing.
TabAtkins: Yesterday we discussed flex-basis because
flex-basis: auto is just deeply confusing
TabAtkins: fantasai came up with a suggestion. Since flex-basis
isn't used much and people are using the short hand, we
may be able to change the keyword and keep flex: auto
doing what it does.
<fantasai> relevant email -
http://lists.w3.org/Archives/Public/www-style/2014May/0192.html
TabAtkins: So flex: auto would turn into flex-basis: change-as-needed
which would be much less confusing.
TabAtkins: Shorthand expansion would be weird but it's already
weird.
TabAtkins: I plan to add a use counter to see what the usage of
flex-basis: auto is and if it's low we can change the
keyword.
fantasai: When we first had this spec auto matched max-content but
with some issues from implementor feedback, it's no
longer the same.
fantasai: Right now there's no way to say explicitly "I want
flex-basis of auto", which is a problem.
TabAtkins: I think that's all the flexbox issues.
dbaron: Do you have a proposal for the new name?
TabAtkins: No.
dbaron: Size comes to mind or use-size.
fantasai: Match-size?
dbaron: I'm trying to come up with something that matches width or
height.
TabAtkins: Main-size.
TabAtkins: It means we use the main size.
dbaron: Is that term author exposed?
TabAtkins: It doesn't show up in any properties. It's extremely
common in the spec but not used in syntax.
dbaron: That seems reasonable to me.
fantasai: So we can draft that up.
<trackbot> Created ACTION-627 - Get usage data [on Tab Atkins Jr. -
due 2014-05-27].
<trackbot> Created ACTION-628 - Draft a concrete proposal [on
Elika Etemad - due 2014-05-27].
<trackbot> Created ACTION-629 - Draft a concrete proposal [on Tab
Atkins Jr. - due 2014-05-27].
plinss: Do other flexbox implementors have opinions on the change?
Rossen: Should be fine.
fantasai: So that's where we are. I want to go over aspect ratio.
fantasai: The simplified version is if we have 100 x 100 image and
set width: 50px and height: max-content
fantasai: What's the size of the image?
dbaron: Max-content shouldn't depend on specifying width or height.
fantasai: It does.
dbaron: It should depend on specified width or height inside, but
not on the element itself.
fantasai: That's not true on a paragraph. If I set width: 50px the
max-content height will depend on that width.
dbaron: That's what happened when you define max-content?
dbaron: I don't like that definition.
TabAtkins: It doesn't do anything useful otherwise.
dbaron: It would be nice to pick something that didn't depend on
width or height.
Rossen: In the case of image I would expect it to be 50 x 100.
TabAtkins: That's what spec says I think. That's not certain.
TabAtkins: I don't think I like it but I'm confused.
dbaron: I think if you want to try and define you'll end up with
circular cases for some combinations for max and min
width/height and content.
TabAtkins: We're trying to avoid that with visibility hidden and
min-width content. For something with an aspect ratio
the height affects the width so it needs to feed in.
fantasai: We have two options. One is to build smartness into auto.
The other is to redefine min- and max-content to account for
author spec constraints.
dbaron: I'd rather the first one.
fantasai: Okay.
dbaron: I'd rather keep min/max-content like primitives.
Rossen: Plus, we're close to get getting the first option.
Rossen: To get unblocked I'd go with defining how auto works to
the extent we can for edge cases.
Rossen: There will always be more edge cases.
fantasai: Okay. We'll work on that.
fantasai: I think that's it for flex. And we're doing the CR
version of the algorithm?
fantasai: Did we discuss that?
TabAtkins: If we didn't we should resolve.
dbaron: CR being the older one.
TabAtkins: The one based on the older one.
fantasai: So let's remove that at the last moment before we publish
Keep it until right before publishing.
fantasai: So people can find inconsistencies which are indications
that we screwed up somewhere.
RESOLVED: Publish Flex CR with the CR version of flex distribution
algorithm.
TabAtkins: And we're going to say no to the proposal of Flex to PR
since we know it isn't ready.
plinss: What will it take?
TabAtkins: More tests.
plinss: Do we have a plan for getting there?
plh: When you say more tests, do you have an idea of what's needed?
TabAtkins: I haven't done a significant review, but I was told
that there weren't enough.
plh: It would be nice to have this, have somebody to tell us what
needs to be tested.
plh: Sometimes people come to us asking about what tests to write
and I can tell them to write tests for this and this in flex.
TabAtkins: Okay.
plinss: So you're taking that on?
TabAtkins: Yes.
plinss: Do we have a test plan doc? It doesn't look like it.
fantasai: If there aren't 1,000 tests, there aren't enough.
dbaron: It looks like there's 400ish.
TabAtkins: So we have half as many as we need.
fantasai: Likely more like a fourth.
dbaron: I think some are relatively complicated tests.
dbaron: Which can pack a good bit in.
dbaron: I'm curious about there being only one test for flex lines.
astearns: When I last looked there were none for line.
dbaron: It might be they're pointing to different sections.
dbaron: We have a bunch pointing to baseline that are testing
multiple lines.
dbaron: Maybe not.
dbaron: If I look at the directory of rough tests, there's a
substantial number of commit messages for line, but none
of them point to multi-line.
TabAtkins: Okay.
dbaron: A bunch are for baseline and there's a commit for rough
tests for multi-line
TabAtkins: I was coaching someone through writing a bunch of
multi-line tests in Japan. Maybe they weren't reviewed
or just not pointing right.
plinss: Okay.
plinss: That's it on flexbox?
plinss: Chris isn't here, but should be, so let's start on CSSOM.
dbaron: I just discovered that's a subdirectory that my import
didn't contribute.
dbaron: Wait a minute. That's because it no longer exists. I don't
know what happened to it.
CSSOM and CSSOM View
--------------------
zcorpan: State of CSSOM and CSSOM view
zcorpan: The big items that need work in OM are serialization,
which is kinda broken in general. It doesn't do the right
thing for short hands.
zcorpan: I think it doesn't support all of the things the CSS
supports.
astearns: I think there was a proposal to take the serialization
rules for background and apply them generally.
TabAtkins: I think we discussed that at previous F2F and I don't
recall outcome.
Rossen: We discussed it in terms of shapes. If you find that
discussion it'll help.
zcorpan: If someone finds that discussion, would they file a bug?
dbaron: With the serialization there's interoperability between
browsers with weird variations and we don't want to break
existing interop. We've done that in the past.
zcorpan: So we might have to make the spec property context
sensitive.
dbaron: It might be dependent.
dbaron: It's not to a point where I would trust the spec to change
a browser's behavior
zcorpan: I wouldn't recommend that.
zcorpan: If you have opinions about how it should work that would
be helpful.
dbaron: I have some general opinions. I think I've told you them
before.
zcorpan: File a bug, please, and write them down for me.
<astearns> I believe the idea for serializing shorthands would be
to use the rules I added for the <basic-shape>
functions in
http://dev.w3.org/csswg/css-shapes/#basic-shape-serialization
(paragraph 1, not paragraph 2)
zcorpan: Anything more on serialization?
glenn: Question on calc(), is there serialization rules there?
TabAtkins: Nope. So, there is a question, as we define new
functional forms, should that be in each spec or
centralized into CSSOM.
zcorpan: No opinion.
glenn: I think we should make them closer or you have to rewrite
CSSOM every time.
dbaron: But CSSOM can define useful things for that spec to
reference.
glazou: As far as I'm concerned the biggest problem is gradient
and transform for serialization.
glazou: That is probably the highest for me.
TabAtkins: And I defined it sometimes when I defined the spec.
TabAtkins: I'd like a general rule for properties even if we have
to violate that for legacy.
TabAtkins: I want to know what to do about serialization.
hober: Even if there's a world with pattern A and pattern B and we
can reference that.
<astearns> logged a bug on serializing shorthands:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25822
zcorpan: Style sheet loading is kinda broken. It doesn't say to
parse the style sheet. It says load this and the
style sheet appears.
TabAtkins: It should all be hook-able.
zcorpan: Likely nothing is preventing that, but I haven't had time
to fix it.
zcorpan: There's also cross-origin which might be some of it.
TabAtkins: Do you have plans for a constructible style sheet?
zcorpan: You can do that with insertRule. I have to write CSS
syntax, but there are no constructors for each property.
TabAtkins: Style sheet objects themselves. I have things we
discussed internally to make style sheet handling
easier, but I'll discuss that on the mailing list.
glazou: document.createStylesheet or something?
TabAtkins: Something to have more explicit sharing.
zcorpan: Anything to add to style sheet loading?
zcorpan: The open bug count is 31.
zcorpan: From what I can tell the immediate implementation
interest is css.escape() and CSSOM values
zcorpan: TabAtkins had a proposal to make it better.
TabAtkins: JS value objects. That won't be another year or two and
a good API isn't implementable until we have that.
zcorpan: A colleague was interested
glazou: I am too. I'm not sure it's the right direction, but it's
something I wanted to us. For CSS values outside of JS.
zcorpan: Are people looking to implement other parts?
zcorpan: CSS.escape() lets you take a string and have the value
escape parts of a selector or a string that goes into
content that you can use in insert group.
dbaron: A lot of CSSOM is in DOM level 3 style and already
implemented.
plh: I see this was last published in last December. Have there
been substantial updates that make this out of date?
zcorpan: Not too much. I added the dashed property things.
TabAtkins: For custom?
<TabAtkins> el.style['background-image']
zcorpan: No, not custom properties. I think it's a CSS style
declaration? We investigated dropping it and the usage
was too high.
zcorpan: There were other minor changes, but not much has happened.
zcorpan: I plan to do more on this after the summer.
zcorpan: The CSSOM View spec.
zcorpan: There's an open issue on how things should behave for
scrolling.
zcorpan: The spec has right now something no one wants to implement
zcorpan: Microsoft or IE has logical behavior for some things, but
not all.
zcorpan: Firefox uses physical behavior for all the things.
zcorpan: So it's more consistent and understandable and in line
with how positioning works if you look at abspos.
zcorpan: So I'm inclined to match Firefox in the spec.
Rossen: What's the example?
zcorpan: [white board]
<dbaron> whiteboard drawing:
http://lists.w3.org/Archives/Public/www-archive/2014May/att-0007/dsc06430-zcorpan-whiteboard.jpg
zcorpan: Let's say this document is right to left and you have a
case of a smaller viewport than canvas and you ask for...
zcorpan: It to scroll left on the document element.
zcorpan: Firefox approach is the top left point of the viewport is
the origin.
zcorpan: And right is the positive axis so greater values are on
the right.
zcorpan: If you scroll to the left you get negative values.
zcorpan: IE has the same origin but the axis is in the other
orientation.
zcorpan: This is the same as how top and left work in CSS.
zcorpan: It's also how the coordinates work in, I think, all
browsers and also some properties. I don't remember
exactly which ones.
zcorpan: There's messages with the details in the mailing list.
fantasai: If I was going to do this over I'd move the origin to
the other side, but if that's inconsistent with how
other coordinate systems work than that's not helpful.
zcorpan: And it's not clear to me that the mouse coordinates can
be changed to the IE model. That seems risky and might
break websites.
zcorpan: So I don't think we can switch to IE across the board.
fantasai: Where is the IE origin?
zcorpan: I think the same place.
<fantasai> rossen thinks it's the top right corner.
Rossen: Did you try with regular scroll? Viewports tend to be
inconsistent.
zcorpan: We need to spec both and it would be nice to be consistent
zcorpan: My question is if Microsoft is willing to change or if
Firefox is willing to change.
dbaron: Did you test chrome or webkit?
zcorpan: That's more insane. Chrome is close to Firefox, but
there's a property that puts the origin on the canvas
instead of the viewport.
zcorpan: That's what I tried to do in the spec but it wasn't happy.
fantasai: The problem with the origin being in the middle is
you're just floating out there.
dbaron: And it's nice to have your original scroll be scroll left
of zero.
fantasai: I feel sorry for anyone programming RTL with scrollers
because they're all insane.
zcorpan: I agree, but we need to pick.
zcorpan: My preference is for Firefox because that it makes it
easier to work with abspos.
zcorpan: If you want to position and element where you click, it
can set top and left to whatever coordinates instead of
trying to transform from other origin.
fantasai: I think mouse and scrolling should use same coordinates.
If there's introp on mouse we should copy that.
zcorpan: Should I move on or do people want to resolve or should I
spec this behavior and see what happens?
zcorpan: Opinions?
TabAtkins: I have none.
glazou: I think it's good to spec and ask for review.
glazou: Anyone object to zcorpan specifying this?
zcorpan: GeometryUtils is a new API that lets you get coordinates
and dimensions from boxes after transformation so you can
get...
zcorpan: For instance, get a shape with these four points instead of
getting the bounding box.
zcorpan: How this works is just a big red box in the spec, but I
think Firefox shipped an implementation.
zcorpan: So now I can reverse engineer.
fantasai: Who worked on this?
TabAtkins: Roc did
TabAtkins: And did a lot on the mailing list.
zcorpan: The IDL is in the spec, just not the semantics.
zcorpan: So that needs spec work. Any questions on this?
zcorpan: Any questions?
zcorpan: At some point I should revamp the overall model of how
CSSOM View does it's thing because right now it's too
hand-wavy.
zcorpan: Part of the problem is the specs themselves are hand-wavy
and there's no foundation to build on.
zcorpan: It's not spec'ed how to make a render tree and how to
make boxes from it, it's just described how the end
result should be.
TabAtkins: We need a render tree description and a description of
how hit detection works.
zcorpan: So it's an issue that needs to be fixed.
zcorpan: Part of the model problem is the CSSOM specs are unclear
about when things happen. When you resize the viewport,
when do we fire the change.
zcorpan: What's the order?
zcorpan: It just says when it happens you do both. That needs to
be better defined.
zcorpan: So we can test and get to interoperability.
zcorpan: Any more points on the model?
zcorpan: So other implementation interests that I can think of is
sub-pixel position which is basically double return values
hober: Which we did five days ago.
<hober> FYI, WebKit changed Element.offset*/client*/scroll* to
return doubles last week in:
http://trac.webkit.org/changeset/168868
zcorpan: And Blink is working on implementation and Opera. IE does
have it for something things and for some things if you
opt-in.
zcorpan: So there is some compat concerns around this. I think
Firefox tried and had to revert because sites broke, but
I'm not sure if that's still an issue. It's unclear.
zcorpan: I guess we'll find out from Webkit and Blink.
hober: I think Roc raised a case where it was banging strings
together to make a class name and when it changed from 0 to
0.0 the selector took on a very different unit.
zcorpan: Was it 0.0 or 0.01?
hober: Doesn't matter.
<TabAtkins> ".foo" + size changing from yielding ".foo0"
(valid selector) to ".foo0.0" (invalid).
hober: If we had CSS-escape() years ago...
dbaron: A lot of these APIs don't account for features on the web.
How much is it worth evolving to account for some of these
things? That's the part of between get.box.quads where it
accounts for transforms.
zcorpan: The argument where people are interested in implementing,
they say that doing this would result in a better user
experience for existing apps.
zcorpan: They use offsetTop and scrollTop and you'd have a
smoother scroll.
zcorpan: We can always do new APIs that do transforms.
dbaron: I think on this one we'll let you take compat risk first.
<dbaron> (We take compat risk first plenty of the time!)
Rossen: Our experience with this...there was a discussion and I'm
not sure if it made it to the mailing list.
Rossen: We tried that, enabling all of the CSSOM controls in
floating points, and we had massive compat issues.
Rossen: At the time, that was IE9, most of the content is relying
on integer math and as soon as we produced floats we had
massive breakage.
Rossen: asp.net servers started choking on mouse events with form
submissions. I don't remember the issue, but we had to
turn off the mouse events floating point because of the
server being unable to handle them.
zcorpan: Do you have a list of APIs?
Rossen: We support something for all the APIs if you turn them on.
That's why they're not on by default. The only one that
is on by default was the one shipped by Firefox.
Everything else is optional.
Rossen: A list of specific APIs that are breaking stuff, that we
don't have
Rossen: It would be easy to browse and observe breakage.
zcorpan: So assuming we find it's not compatible for Webkit and
Blink would you prefer opt-in like IE or a new property?
zcorpan: Some people don't like opt-in since different scripts can
use both and generally people have a distaste for
document-wide switches.
Rossen: Then you end up with mixed content where half is floats
and half is integers.
dbaron: But if you have one library that expects one thing and a
different library looking for another, you don't want to
have to rewrite a library. So I'd be happier with two
properties.
zcorpan: I agree. Would IE be okay with that direction?
Rossen: I don't see why we'd be unhappy.
Rossen: In fact most of the window 8 store apps are using it as on
by default.
plinss: But there's no need to standardize.
zcorpan: Do you know if people are using it on the public web?
Rossen: I don't know but I can find out.
plinss: This ties into a later topic but I think that all these
APIs are broken so I'm reluctant to add new ones. I'd
rather a proper box model and put the good APIs on that.
zcorpan: So you don't want a fix soon, you want to wait on the
better APIs?
plinss: I want both. I want the better APIs soon. In general I
don't want to spend too much time fixing presentational
APIs on the DOM, I want to get a proper API. I want to
expose the box tree and have APIs that work on that.
dbaron: One point of order, do we have something from 1pm to 2pm
that has to go in that slot because if so we need to break.
zcorpan: Should I continue after lunch? I'm almost done.
zcorpan: The other thing I've seen interest in is smooth scrolling.
That's a new thing and lets scripts opt into letting the
user agent do a smooth transition when the script scrolls
or you navigate to an item.
glazou: It's to enable/disable smooth scrolling, or it's to spec
how it will scroll?
zcorpan: You enable a point that you're scrolling to. This is an
opt-in to scroll to this point but smoothly.
dbaron: Is the scroll behavior or something else?
zcorpan: Two things. There's scroll behavior that lets you opt in
and there's a dictionary you can spec when invoking
scroll API.
dbaron: I like the dictionary, I'm not sure about scroll behavior
as a property.
zcorpan: Can you elaborate in an e-mail?
dbaron: Okay.
zcorpan: And then there's GeometryUnits. I'm not sure if other
browsers want to implement that immediately. That's all I
have.
glenn: Since the DOM 4 was moved to HTML and CSSOM is important to
HTML 5, has anyone thought to move this to HTML since API
is a big priority?
plh: I don't think it's a good idea. CSSOM has been the hot potato
and it needs to be done.
hober: zcorpan is here and doing the work so let's do it here.
zcorpan: I don't have an opinion.
plh: I think this group is the right one. You guys know the
complexities. I think the dependency plan is to say CSS isn't
in REC, but lets face it, it was part of DOM 3 and there
aren't any major details changing.
plh: Th plan is to say it's not a REC and that's fine.
zcorpan: Okay. Lunch?
[break = lunch]
Received on Wednesday, 11 June 2014 13:02:51 UTC