- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 14 Sep 2015 13:59:21 -0400
- To: www-style@w3.org
Page Floats
-----------
- RESOLVED: Publish FPWD of Page Floats
Writing Modes
-------------
- RESOLVED: Make the caption-side: top | bottom values logical,
drop logical keywords.
- RESOLVED: Propagate 'direction' and 'writing-mode' from BODY to
FOO (HTML if not BODY). To be reopened if tests show
this isn't the way it's being done already
- RESOLVED: Switch to the new model, mark sideways-lr and -rl as
at-risk. Revisit if jdaggett objects because he's not
here.
Snapshot 2015
-------------
- Those present were generally positive about the new text, but
some key individuals were missing, so the final decision will
happen on the next telecon.
Flexbox % Follow-Up
-------------------
- There was new input for the conversation that the user of
percentage margin will reduce as grid and flexbox are used
more, however there was still no conclusion.
===== FULL MINUTES BELOW ======
scribe: dael
Page Floats
===========
johanneswilm: We would like to have a FPWD on this. More
importantly we have some doubts as to who this
interests. We can implement what we have now, it's a
relatively basic model, but we would like to know if
this is interesting at all to browsers or if we
should make it more advanced. If you want to do
print you want more.
johanneswilm: What we have only works in fragmented contexts. In
any single fragment you can only have floats in the
line or block direction. So say you want a float
that goes to the right in a fragment that goes to
the top, the float will move on. And you won't have
2d floats.
johanneswilm: And as liam pointed out on the list, you would want
to have a way of stacking those floats. Right now
they are displayed in document order, but you might
want two floats in a document with a large float
that's at the top, you might want the two small at
top, but that's a more complex description.
Florian: So there's conflict between what you want and what is
implementable by browsers.
TabAtkins: And what you can reasonably spec.
Florian: And depending on what interest, if the browsers say we'll
never do this, we can go for the fancy thing, but that's
not a desirable outcome. That's the underlying tension.
Florian: Maybe having the general model supported and a switch
saying do it slow and fancy.
TabAtkins: If you're doing a custom printer thing you can do what
you want.
Florian: The printer and web aren't disjointed.
TabAtkins: But high quality printing is different.
Florian: And an ebook is in between.
TabAtkins: If you're doing a pixel perfect thing that's fine and
you can use magic, but we don't need it on the web.
liam: I don't think it's pixel perfect.
TabAtkins: But with the small things you can adjust your sizing.
Florian: Since we're working with active media, it's not inDesign.
You're writing a style sheet for print, but that means
it's for paperback and hard cover and kindle.
TabAtkins: But if you want ideal design that is what you want or
you're a smart formatter that can do the magic, go
ahead. We're not going to do a make my page magic
script.
johanneswilm: We do it on top of you, that's fine. Last time
Rossen presented something that's simple page floats
but wouldn't work with more than one in a column,
the basic version we have should be able to handle
that. If browsers are interested in that, we'll make
sure the spec is written so that you can use that.
If you don't care we'll write advance stuff.
dino: Is the simple thing of use to authors?
johanneswilm: Yes. When you start to make things more complex it's
not.
TabAtkins: We're not against the idea, especially if they start to
obey simple restrictions. Something to remove the
craziness of floats. So if you're doing newspaper
layout you make the images siblings of the paragraphs
not children you're fine. We're fine with this though
we may have more feedback on the exact details.
dino: We'd be interested.
johanneswilm: What would you guys need for us to do FPWD?
ojan: The thing Chrome is most interested in, we haven't reviewed
everything, but extending floats in general we'd like a
caret approach so we can remove the crap features from
floats.
TabAtkins: That might manifest by saying these aren't floats,
they're a new property.
SteveZ: Is there a list of these things you want to get rid of?
TabAtkins: We're making it, yes.
Florian: Do you want this addressed before FPWD?
TabAtkins: I don't think so. I'm happy to not block now, but our
review might involve lets put more restrictions on this.
Florian: I think the goal is to make something which is both
useful and implementable in browsers without major
headaches, so we should be able to converge without
problems, at least not philosophical ones.
TabAtkins: We don't have philosophical problems.
TabAtkins: I'm okay with pubishing FPWD.
plinss: Objections?
RESOLVED: Publish FPWD of Page Floats
plinss: Anything more?
plinss: Do we loop back to writing modes? jdaggett still isn't
here.
Florian: We deferred to the F2F to have him.
plinss: If we don't get him, should we do it here or wait for him?
fantasai: I think we should get through it here and jdaggett can
add his thoughts and all resolutions are pending his
thoughts.
Writing Modes
=============
<fantasai> https://drafts.csswg.org/css-writing-modes/issues-cr-2014
fantasai: I have a DoC linked above.
fantasai: I'll skip to issue 2.
caption-side
------------
fantasai: There is a caption-side property in CSS that defines
what side of the table you put your caption. It takes
top and bottom and in the past it took left and right.
Mozilla implemented them all, but we dropped the sides
because no one else did. Now we have writing modes and
if you don't have the sides, you can only do block-start
and block-end. So we have top and bottom keywords, we
want left and right. And since those are physical, when
you go into vertical, they stay physical.
fantasai: But if you don't support all four values you have to do
something about that. [whiteboards]
fantasai: If you only support top and bottom and you implement
writing modes, you can't put "top" at the top in
vertical mode, because it's a side-caption, which you
don't implement yet.
fantasai: So we need to map "top" and "bottom" to over/under
captions. We decided top and bottom should go to the
default caption side, the block-start side.
fantasai: We added new keywords of block-start and -end keywords
and made the initial to be block-start.
Rossen: This is what we're implementing. We ended up mapping top
and bottom to be logical, just like for float where left
and right mapped logical.
fantasai: Float left and right maps into the line left and right
which are logical, but not start and end. It means float
to wherever left and right text will start.
fantasai: If I have right to left text, right is the start but not
the left.
fantasai: We could put top and bottom as logical, but what happens
to Mozilla where they can do that as side captions on the
actual top and bottom--it becomes incompatible.
Rossen: We implemented left and right and we dropped it.
fantasai: Because nobody supported.
Florian: Having left and right without vertical writing is not so
nice.
Rossen: There are cases.
fantasai: If you have a table and side captions on the right, it
looks ugly and no one wants to use it. It doesn't look
attractive unless you support vertical writing also.
fantasai: We all agreed to add logical equivalents and we want
authors in vertical writing modes to use those.
fantasai: We wanted it to be clear that the caption-side physical
values don't have an effect in vertical writing modes.
fantasai: Do you want top and bottom to behave logically or
fallback to the block-start?
Florian: It's a usability question, not feasibility.
Rossen: We have real use cases where people use vertical tables
with captions, mostly for displaying odd tabular data. I
don't know about them, but they were using top and bottom
just fine.
fantasai: It's totally logical, but as soon as you support side
cations, top needs to be on the actual top.
fantasai: The ones in Mozilla are in the e-mail I wrote. Side
captions don't exist right now, but people want them.
Florian: Can left and right be logical?
fantasai: That's opposite of how it is everywhere else.
Rossen: What about rows and columns?
Rossen: You're making everything in the table logical.
fantasai: So you're suggesting drop block-end and -start and
decide that top goes on the other side?
Rossen: All table properties are in a logical way without
redefining them with logical properties. Just like we do
for rows and columns.
ojan: I wish we had done that for the whole platform, but it's too
late.
fantasai: So this will be an exception to the rule that
top/bottom/left/right are physical keywords.
Rossen: For tables only. It's legacy feature retrofit into writing
modes.
fantasai: Anything else to add?
Rossen: Otherwise you're half logical and half physical.
fantasai: I don't buy your argument. Margin-left and margin-right
are all physical. The only thing logical is caption-side.
dbaron: I think of table captions as a feature that was a mistake,
since authors can just use other markup and style to put
the caption next to the table, rather than having browser
features to move the caption from the inside of the table
to the outside.
dbaron: So I kind of don't really care. I'm tempted to just remove
the left and right support from Gecko except that's work
and I don't see the point of doing that.
<tantek> +1 on removal
Rossen: Comment out the property support.
ojan: Sounds great to me for what it's worth.
fantasai: dauwhe, do you have opinions?
dauwhe: I got a request from a friend of mine in publishing that
had been switching to figure for a11y and wanted figure
caption display the same as caption inside table and we
had to get those to be the same. So there's a movement
away from caption.
tantek: He likes how caption displays??!??
<tantek> caption element is so broken that the more we unsupport
it the better
dauwhe: It's fairly easy to get it to follow the length.
fantasai: It only works in Mozilla. The combination you want is
writing modes plus side captions and no one has that.
Florian: You can do it...
fantasai: With?
Florian: Multi elements.
fantasai: The way side captions are defined is if you're centering
it you're centering the table and this is off the side.
* fantasai draws how this works, see
http://fantasai.inkedblade.net/style/discuss/captions/
dauwhe: I'd like to take this use case back to dpub.
fantasai: That's what a side caption does, but that's besides the
point. All that matters here is its been proposed to
drop the block-start and -end and make caption-side a
logical property.
TabAtkins: If we should drop side captions, I don't see why not
treat them logical? We call it line-top or whatever.
Sometimes you got to retrofit.
fantasai: How it maps goes in writing modes.
Rossen: Sure, you can have an exception.
<tantek> why is this only about tables?
fantasai: We have to spec for 2.1, we're not waiting on CSS3 Tables.
fantasai: So the caption-side property which currently takes top
and bottom, or if you support side captions also left,
right. We also added block-start and block-end. The
proposal is to remove block-start and -end and to make
top, bottom, left, and right logical
Bert: I prefer the solution in the ED, but I see why people want
the other. I'd rather add more keywords for logical
directions.
fantasai: Anything else to add?
Florian: I agree with Bert. I prefer the other but only mildly.
fantasai: Any objections to making the caption-side property
logical?
RESOLVED: Make the block caption-side property logical
Propagation of Direction to Body
--------------------------------
fantasai: Propagation of direction to body. Unlike 'background'
propagation from the body tag to the viewport, we don't
have a 'you didn't set this value' value. Every element
has a value for writing-mode and direction. We got
some feedback that there's web compat issues so we
should propagate from the body tag to the viewport.
The compat problem mostly comes from epub and people
using writing modes and wanting to propagate direction
from body.
fantasai: So first options is don't change the spec, you only use
the writing mode and direction of the root element and
the direction attribute goes from body to HTML.
fantasai: Second is the viewport and initial containing block use
the writing mode and direction of the body.
fantasai: Third is we ignore the direction and writing mode
property on the body and copy that only the root element.
dbaron: Didn't we spend an hour or two on this at a previous
meeting?
Rossen: I thought we would do what we did for background property.
Rossen: That's what current implementations do.
fantasai: We had a resolution to not propagate direction from
body, but then thought there might be compat concern for
not propagating writing-mode.
esprehn: I don't think we can change.
fantasai: Everyone is buggy on what aspects they propagate up.
fantasai: You can say for each effect that gets propagated, use
the direction but the computed value on the root isn't
changed. The other is change the writing mode and
computed value on the root which would keep everything
in sync.
Florian: Both these are done in browsers?
fantasai: No, this is what we can put in. Browsers are incomplete
in how they translate it. Scrolling is inconsistent.
Stuff is buggy.
Florian: Buggy how?
fantasai: In that people have bugs and only propagate for some
effects, but not others. Nothing depends on it being
broken. Some of it depends on stuff working. We can
define the propagation in two different ways, what is a
better way to do it?
Florian: You're suggesting here are a few things that would keep
compat, which is easier to implement?
fantasai: First we could propagate 'direction' via the HTML 'dir'
attribute [as we discussed at the last F2F] instead of
propagating the 'direction' property if direction is the
only thing we care about, but it doesn't handle writing
mode.
fantasai: The second is the way implementations sort of do it now.
fantasai: The third would be a different approach to doing it.
fantasai: Either way people have to fix implementations.
fantasai: No matter what we pick we'll have to do work.
koji: I'm not familiar with direction buggy, but if author
specifies on HTML or body the three browsers are quite
similar. As long as either is honored, the web compat is
good, at least for writing mode.
fantasai: We can't detect if the author specifies a value for
<html> or not. There's no 'none' on writing mode.
The computed value is one thing or the other thing.
fantasai: Background has a transparent value and that's the initial
value. If you set it to color or image, we can see the
author set it to not the default.
fantasai: So to propagate from <body> we would be completely
ignoring writing-mode on the HTML because we can't tell
if the author set it.
fantasai: The question is do we change the computed value on the
HTML element or do we leave it computing to what it had
and take all the effects, scrolling and alignment, and
make them depend on the body alone?
Rossen: That's what current implementations do. How they got on
body no one cares.
Florian: And you don't retro-fix the HTML. Seems simple enough.
esprehn: It does this.
Rossen: It's already simple enough to explain so if we keep it
this way it's better.
fantasai: The advantage of copying is if the entire author says
the whole document is this, you get it into the metadata
at the top and the logical properties behave the same
way on the root as it does elsewhere on your document.
fantasai: You do the inheritance up and then you don't have to
special case code for the scrolling and the like. As
long as you did upward inheritance it will all just work.
You don't have to handle each of these individually.
It's clearly an implementation bug that things aren't
there, but there's more opposite to trigger that switch.
Florian: So it's one complicated fix or a bunch of simple ones and
you forget half of them.
fantasai: Does that makes sense?
dbaron: I'm trying to find the list from the last discussion.
dbaron: I'd be worried about time switching to something that
doesn't match what everybody does.
Rossen: The only thing that propagates up is overflow, writing
mode, and background.
ojan: You said the direction doesn't get property.
Rossen: To the viewport.
esprehn: fantasai is asking us to inherit everything up into the
view. That's not what anybody does today.
esprehn: The body inherits into the root.
<tantek> upward propagated? or hoisted?
[whiteboard]
Rossen: Overflow writing mode and background on gets cascaded to
body. As soon as we have the cascade down to body, they
upward propagate to the canvas.
fantasai: There's two ways to get this. If you don't have a body
you have to have code for getting from HTML to canvas.
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Mar/0188.html
dbaron: The list I had that astearns found had 4 things:
1) Which side you can scroll to when there's overflow from
the viewport.
2) If the root element is relpos and has both left and
right set, which one wins.
3) If the root element has overconstrained margins, which
gets ignored.
4) If the root or body is abspos, which position gets used
for hypothetical box calcs.
dbaron: 1 and 4 are the main compat risks.
Florian: I believe fantasai's point is if you do reverse
inheritance you can't forget to handle one of those on 4.
dbaron: I believe we can't fix it. People already write script.
dbaron: Also the code for the other thing we do in 4 is awful. The
code for reverse inheritance.
dbaron: Do we even still do reverse inheritance of the other
property?
fantasai: Overflow, background, cursor (maybe), direction and
writing mode propagate up.
ojan: For good measure, we don't do cursor, we do image-rendering
and column gap.
Florian: By spec cursor goes from root, not from body.
fantasai: So image rendering is because it effect background.
esprehn: Yes.
fantasai: Backgrounds and overflow have 'I didn't set this' values
and they will propagate based on if you set it on the
root. If you didn't set it on root it propagates from
body. Cursor direction and writing modes are all
inheritable. You can only tell if you have a body and
you grab it and if you don't you use the root.
ojan: I don't think we do the thing where if the value isn't set
we don't propagate.
fantasai: If you set a background on the root and on the body, you
need to assign the root element to the canvas.
ojan: I think we don't do that for overflow.
dbaron: Background doesn't effect computed values.
fantasai: If you set overflow: scroll on the body and
overflow: hidden on the HTML then you scroll the
document and ignore the hidden?
ojan: I think so.
esprehn: Our code follows the spec. Where's rbyers? You wrote this.
esprehn: We don't look to see if it's set, we look to see what the
viewport is set by and we pick that except for BG.
ojan: The thing on BG is more complicated, just for the record.
<zcorpan> cursor doesn't propagate from body per spec, only from
root. (seems blink follows the spec; gecko doesn't
propagate cursor at all)
koji: The other option is that, I know it's from the last F2F, but
since mostly the combine is about writing modes, we don't
propagate but we just use HTML and body to decide principal
writing mode. I guess thats' what we do. I haven't checked
IE yet.
fantasai: [writes options on board]
1) propagate 'dir' attr, not 'direction' or
'writing-mode'
2) propagate 'direction' and 'writing-mode' from BODY to
ICB/viewport/canvas (HTML if not body)
3) Propagate 'direction' and 'writing-mode' from BODY
to HTML (always from HTML to ICB/viewport/canvas)
fantasai: The first I don't think we can do due to ebooks.
fantasai: I think we can allow either 2 or 3, we can allow both in
the spec, it gets the same result.
Florian: I'm not hearing anyone want to do 3.
Rossen: That was my kind of more general question. Are we trying
to document what everyone does or spec something most
likely no one will implement?
fantasai: What do we want to do to get the content to work in the
future?
dbaron: I think you should start from a table of accurate checked
data of what each implementation does in detail rather
than figure it out in a working group.
Rossen: There's 4 properties and 2 elements to test.
astearns: And these tests should be in the test suit.
dbaron: I think we had a previous resolution to do the same thing
for writing mode and direction, it wasn't defined what
that thing was.
<dbaron> https://lists.w3.org/Archives/Public/www-style/2015May/0313.html
<dbaron> has a previous resolution
<dbaron> I think we should stick to the second relevant one
<dbaron> (I'm quoting indirectly via
https://bugzilla.mozilla.org/show_bug.cgi?id=1169065#c1 )
fantasai: The previous resolution was to handle the direction
property by propagation the direction at the HTML level
so you would only look at the root, but then that won't
work for writing mode if we need to do that. So we can't
use that and writing mode and direction should be same.
Rossen: How about we come up with the test cases.
fantasai: Let's resolve to propagate both and it doesn't matter
how, we'll sort that our later.
ojan: I'm okay with that. If we resolve to spec what browsers do
there would be agreement from the browsers here.
Florian: So we resolve to do #2 and if we discover it's more
complex with test cases we'll deal with it.
Rossen: Yes.
dbaron: I think #2 is prob the most compatible, but we should
check.
Florian: If test cases expose that as not what browsers do then
depending on what we've found we discuss again.
* fantasai waves to r12a
<fantasai> we're discussing writing modes
* r12a waves back
* r12a https://www.w3.org/2015/08/mail.php?subject=https%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fwww-style%2F2015Jul%2F0060.html&;list=
RESOLVED: Propagate 'direction' and 'writing-mode' from BODY to
FOO (HTML if not BODY). To be reopened if tests show
this isn't the way it's being done already.
sideways-left
-------------
fantasai: Next is the sideways-left value
<fantasai> https://drafts.csswg.org/css-writing-modes/issues-cr-2014#issue-41
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015May/0092.html
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jul/0060.html
Florian: This one we agreed except jdaggett.
hober: Sideways-left is when you need to know how long the run is?
Florian: It lets you have Arabic and Japanese and they both go
down and we're switching to a model where you cannot
switch that inline anymore.
fantasai: We're at the issue that's been discussed. I went over it
on the call before.
fantasai: Proposal is to change the way writing mode and
text-orientation are organized to remove sideways-left
from text-orientation and instead add to writing mode
sideways-lr and -rl
Florian: By removing sideways-left from text-orientation it means
we only have sideways and sideways-right which means we
don't need sideways-right. So that applies to some, but
not all writing modes. So CJK works the same. In addition
to text-orientation doing nothing on horizontal, it also
does nothing on sideways-lr and -rl.
Florian: So sideways-lr is the one you put on the left side
caption in English and they do everything you would
expect. It's one value that says do the right thing when
flipping a language on the side.
Florian: In the addition to the implementation difficulty of
sideways-left, another downside is that it was biased to
CJK. We are losing the ability to do downwards Arabic in
Japanese or similar. According to liam they exist. I've
tried to find examples by contacting professors and
eventually that ended up pointing me to r12a after a few
hops. It's rare and we can add it back later if we want
to.
Florian: We can fix it later, but we may never need to given how
few people care.
dbaron: Who is the audience for this topic? One of the people that
cares deeply isn't here. But it's not an empty set, so
okay.
astearns: As far as I understand the proposal I like it and don't
need it described further.
fantasai: The mailing list comments were jdaggett didn't think
this made sense initially and now I'm not sure where he
thinks it is. r12a thought about it for a while and said
he likes it a bit better and all of the questions he's
been getting on writing-mode are from non-CJK users
asking if this will solve their problems. This proposal
would make it more straight forward for those people.
Florian: Given that everyone who cares except jdaggett agrees and
he disagrees less than he used to...we had two threads
one where he said if we do this can we change the name
which isn't an objection.
<r12a> note that i actually think the new approach *solves* some
problems i was struggling with with the old approach (see
https://lists.w3.org/Archives/Public/www-style/2015Aug/0217.html)
liam: You mentioned my name by saying these exist. We had a
question in XSL-FO working group about where an underline
would go in that case, but because someone asked doesn't
mean some one does it. We just had an implementor who was
talking about it.
SteveZ: I don't understand because I haven't looked carefully. It
seemed the critical thing was instead of being engineers
and giving a matrix, you said what do people want to do
and give a label to those things and make those easy to do.
Florian: [goes through and points out how most cases are covered]
SteveZ: For the two verticals I use text-orientation to say if I
rotate the embedded non-CJK things.
SteveZ: Since Japanese are often trying to choose between upright
and sideways.
Florian: Yes. The CJK authors are more likely to be away of having
something like this exist.
SteveZ: Without deep thought I like it.
fantasai: I would have made the initial value upright if we had
thought of this originally.
hiroshi: sideways-rl and -lr are a bit confusing because
writing-mode is to make the characters vertical. Sideways
to make Latin go to the side. In this situation, my
opinion is to get rid of sideways for not and use only
rotate. That's enough for the side captions and think
about bidi in level 4.
fantasai: We don't have to worry about bidi, it's a solved problem.
fantasai: But transform doesn't solve the problems of non-CJK users.
fantasai: If you transform from horizontal text you are not taking
up space in the layout. If you use vertical-lr and try to
use sideways you have a problem where scrollbars and buttons
do not look the right way. A lot of things won't work
correctly.
hiroshi: There might be a lot of discussion concerning sideways-lr.
* Bert 's first idea was like Hiroshi's: transform would do it...
if only it affected layout.
Florian: Maybe there's a middle position of at-risk.
fantasai: Maybe. I think it's a strong use case outside of Japan.
I think web authors would be upset if they couldn't get
the effects that are important to have. As r12a said in
IRC there are a lot of people that cared about those
cases.
Florian: Marking at-risk might be good because if browsers support
them they're okay and Japanese users won't agonize
because they won't be waiting on those for it to progress.
RESOLVED: Switch to the new model, mark sideways-lr and -rl as
at-risk. Revisit if jdaggett objects because he's not
here.
plinss: We're over time, is the more urgent things on writing
modes?
fantasai: That's it.
Mozilla Being Okay with Keyframes
=================================
dbaron: I need to read the text. If I'm okay with it I can edit
into the spec.
ACTION dbaron review the keyframes proposal
<trackbot> Created ACTION-720
Snapshot 2015
=============
<fantasai> https://drafts.csswg.org/css-2015/#experimental
fantasai: How do people feel about the new text? I've gotten
positive feedback, do we want to adopt the new text?
Florian: I do.
tantek: It's good enough to ship. Do the people who objected
before think it's good enough?
gregwhitworth: I'm good.
dbaron: Is this revised since dinner?
fantasai: Yes, I tried to handle your concerns.
smfr: I don't find the "why" things helpful.
TabAtkins: I try to use those when it's a long note that's not
helpful to everyone.
Florian: I think the why is important so it's better not to hide.
This isn't spec level prose with unambiguous meaning and
therefore the why is important.
TabAtkins: Okay.
plinss: Everyone okay? Need more time?
smfr: You talked to hober?
fantasai: About the part he was objecting to. There's three
sub-sections. First was the one hober was unhappy about.
The other two have also been revised based on other
feedback.
smfr: I think we'd like to review internally more because I think
there are people interested who aren't in the group.
tantek: Can we give you to the next telecon?
fantasai: Two weeks?
SimonSapin: Is there a meaning to the green text?
Florian: What changed after dinner...
fantasai: I'll remove the underlines once dbaron says okay.
plinss: So we'll loop back next telecon.
fantasai: I want a sense if everyone in the room agrees.
astearns: I suspect hober will be very interested in the insert
that says support for prefixes should be removed.
Florian: This is the model where prefixes are shipped early when
unstable and then once it ships the regular version
should be used. Since we don't live in the perfect world
it might work differently. This isn't you should remove
the old fashioned prefixes.
plinss: Anyone in the room have comments?
fantasai: Positive or negative.
fantasai: Type +1 if you like it -1 if you don't, 0 if you don't
care.
<tantek> +1
<plinss> +1
<Florian> +1
<dauwhe> +1
<leaverou> +1
<ChrisLilley> +1
<rachelandrew> +1
<liam> +1
<MaRakow> 0
<SimonSapin> +1
<gregwhitworth> +1
<jet> +1
<astearns> 0
dbaron: I might have worded one of the thing differently.
fantasai: Suggest edits.
<dbaron> Vendors should make it possible for other implementors to
freely implement any features that they do ship. To this
end, they should provide spec-editing and testing
resources to complete standardization of such features,
and avoid other obstacles (e.g. platform dependency,
licensing restrictions) to their competitors shipping the
feature.
plinss: We'll loop back to this on telecon.
Florian: Do we discuss in 2 weeks or resolve for now.
plinss: We're expecting more feedback so we'll resolve in two
weeks.
Flexbox % Follow-Up
===================
TabAtkins: There has not been further discussion.
tantek: Only further thing I remember is looking at the way abspos
handles percentage in general is internally inconsistent
in abspos. You've got top where percentage is height and
margin where it's percentage in width etc. So in all the
different ways there are potential trade offs. Changing
vertical percent on abspos elements to also be percent
height based makes it more internally consistent. All the
horizontals become width based and verticals become height.
That adds more weight to option 3.
tantek: I don't know if that changes anyone's opinion, but it may
add more weight to solve this disagreement.
plinss: Anyone who weighed in have you changed your minds? Or
people willing to raise new objections?
tantek: There was new information to keep considering this, so who
knows if someone will find more information.
fantasai: The other thing tantek brought up--note I totally
disagree with block being legacy--but the usage of
percentage will be much reduced because in the kinds of
layout where you'll want percentage margins and padding ,
you'll probably be in grid or flex and not block.
<tantek> agreed with fantasai
plinss: Alright.
plinss: It sounds like we can't close this, so continue discussion.
esprehn: Would you withdraw your objections to withdraw your
objection to flexbox if we pursued the sane mode property?
tantek: I think this would help move a mode forward. We could
treat this like an error where the web community says
they're fixing this or they say this is crazy stupid and
helps us judge if the sane mode would be judged as sane. I
see this as a good idea and a way to gain market feedback.
Does that make sense?
esprehn: Yes.
Jet: Does Microsoft and Google both have interoperable shipping?
gregwhitworth: They're not the same.
jet: We're about the ship.
dbaron: We shipped already.
gregwhitworth: Microsoft Edge and Flexbox agree and Mozilla. In NY
the abspos situation was brought up. And as tantek
says we'll continue the discussion.
tantek: It's clear we have to say something. But it's more clear
to me this is the way to solve it.
<tantek> the way being dimensionally consistent
ojan: We can experiment in Chrome to see if there's mostly mobile
content that would break, but I don't know if that's useful.
gregwhitworth: By all means share, but it's not like we don't do
mobile testing. You have much larger market share.
I think that Apple would have the same.
gregwhitworth: I don't know how many hundreds of millions we do,
but I receive a lot of bugs so we test a lot.
ojan: On Tuesday gregwhitworth you said you could find us a list
of sites that use percentage in margins. If you could bring
that, it would help.
ojan: I'm trying to understand the non-aspect ratio cases.
tantek: Did we capture that there's user demand for aspect ratio?
TabAtkins: It's in the minutes. Lots of times.
plinss: We are adjourned. Thank you Mozilla!
Received on Monday, 14 September 2015 18:00:19 UTC