- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 Feb 2017 20:28:48 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Expanding our help for SVG
--------------------------
- Rossen informed the group of the proposal for the CSSWG to take
over the parts of the SVG2.0 spec that are felt to be stable.
- ChrisL had edited the proposed scope of work into a draft update
to the charter for review: https://www.w3.org/Style/2016/css-2016+svg.html
- The arguments in favor of this approach centered on this group
having the expertise to do the specification and having a need
to see interdependencies resolved.
- Concerns raised include a concern that without a test suite it's
very hard to know what's stable and that the group won't be
able to deliver on the spec if those planning to work on it
are no longer available to work on it.
- Conversation will continue to answer more questions and come to
a conclusion as to if the group will take on this work.
CSS Alignment
-------------
- RESOLVED: Restore the accidentally removed text from css-flexbox
specifying how flex applies to table wrapper boxes
(https://drafts.csswg.org/css-flexbox/#change-2015-anonymous-fixup)
- There were three options to address the disparity between how
CSS Align and CSS2.1 deal with last baseline alignment of
scrollable boxes:
A) if 'overflow' is not visible, use the bottom margin edge,
ignoring the contents
B) use the last baseline, but if overflow is not visible, then
clamp that to bottom margin edge
C) if overflow is not visible, scroll to the bottom then use
the actual baseline
- Conversation will continue on the github issue.
- RESOLVED: Republish CSS Align CR.
CSS profiles in future snapshots
--------------------------------
- RESOLVED: Add a warning note to all profile notes (mobile,
print, tv) saying they are obsolete and if people want
to see what the WG is doing they can go to the
snapshot.
- RESOLVED: Stop linking to obsolete profile notes from the CSS
snapshot.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Feb/0043.html
Present:
Rachel Andrew
Rossen Atanassov
Bert Bos
Bogdan Brinza
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Dael Jackson
Brad Kemper
Chris Lilley
Myles Maxfield
Michael Miller
Anton Prowse
Melanie Richards
Florian Rivoal
Jen Simmons
Greg Whitworth
Steve Zilles
Regrets:
Tab Atkins
David Baron
Brian Birtles
Tony Graham
Vladimir Levantovsky
Alan Stearns
Expanding our help for SVG
==========================
Rossen: Hello everyone!
Rossen: Are there any additional agenda items?
<ChrisL> https://www.w3.org/Style/2016/css-2016+svg.html
<ChrisL> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FStyle%2F2016%2Fcss-2016.html&doc2=https%3A%2F%2Fwww.w3.org%2FStyle%2F2016%2Fcss-2016%2Bsvg.html
Rossen: This was the result of conversations starting in TPAC
where it became clear the SVGWG was slowing down. Since
then there have been efforts to keep the WG going, but
it's pretty much disseminated itself.
Rossen: There's only a few implementation members and invited
experts left. The implementation experts are also part of
CSS.
Rossen: After discussion with w3c management, plh, and contacts
-astearns and I were in those discussions- the most
favored path from w3m and plh is to capture the SVG 2.0
work under the CSSWG and drive that to completion.
Rossen: That proposal entitles us to do this. The SVG2.0 was
declared final.
Rossen: The parts that are unstable were moved to different
modules.
Rossen: Those modules will move to incubation.
Rossen: The work that happens to fall under our charter will be
the SVG2.0 core spec, the SVG a11y module (which is
stable) as well as SVG integration spec which was
something we agreed to take over in Seattle F2F.
Rossen: Procedurally the way we will drive this so we're not
taking time away from WG as much as possible we will have
BogdanBrinza from Microsoft join the CSS WG and help us
facilitate a track of parallel work on SVG. Similar how we
handled graphics and text separation in Seattle.
Rossen: During the graphics discussion discussing transforms we
had issues we could have resolved if we could have said
that it would work for SVG.
<tantek> I'd like "parts that are unstable" to be clarified
further, or rather, if it's not prototyped (as of today)
or at least partially already implemented in a browser (
i.e. at least shipped behind a flag), it is considered
"unstable"
Rossen: I am looking forward to this. I know there's a number of
you on the queue. I'd be happy to take questions, but I
want to time box this for 5 minutes because we have a
large agenda.
Rossen: I also want to point you to the links from ChrisL above.
He also agreed to change the charter text. Look at the div
that captures the deliverable expansion.
Florian: You said the unstable parts are split off. When was that?
A few days or longer ago?
Rossen: This was part of what BogdanBrinza and I did with SVG for
18 months. TPAC 2014 is when we rejoined and started to
separate unstable pieces into own modules. That was done.
I can point you back to our tracking system for that and
the decision matrix.
Florian: Based on that, for what's left, is that only what was in
SVG1.1 with refined wording, or new features?
ChrisL: New features, yes. Primarily html client integration
clarity. It has aria but we think that can be tested.
Florian: Unless there was a recent change, I'm suspicious it's
stable given it doesn't have a test suite. This is a
massive spec. From a distance I feel taking this to rec
would be as much work as 2.1 to rec. This isn't a small
piece of work.
<gsnedders> Florian: +1
<glazou> Florian: +1
<tantek> I am also suspicious of the claim it's stable
Florian: Even if the crazy parts are removed what's left is
enormous. I'm worried.
Florian: Second point is this discussion of merging SVG hasn't
happened in the AC forum.
ChrisL: This is normal. A draft goes to WG first, then we send
notice to AC, then when charter is ready we send it to
them for review. This is the normal process.
<glazou> +1 on what Chris said
<tantek> Chris +1 makes sense for the WG to review / consider an
additional draft first, then go to AC to ask permission
to expand charter if we choose to pursue that path
Florian: We were ongoing review of SVG charter that didn't say it
was dead. That charter wasn't accepted or rejected. We
were in the middle of discussion.
ChrisL: I think plh sent something out saying charter review has
failed. Did that not happen?
??: It did.
Florian: Okay. Maybe it did.
glazou: One comment. ChrisL called me a few days ago to discuss
this. I think having SVG inside the WG will rely on few
people for lots of work. I think if we don't have these
important people we can't do SVG and we should say that.
glazou: Otherwise some ACs will require deliverables to be
delivered. If we don't have the right people, the WG will
fail.
BogdanBrinza: SVG being too big concern- we're fully committed to
it.
BogdanBrinza: glazou's point, we do have the right expertise and
motivation.
glazou: You have a full commitment on 8 Feb 2017. We know things
and companies change strategy. It is good now. I'm not
sure it's good a year from now.
glazou: That's why I wanted to say without the right people we
can't commit.
<glazou> Rossen corporate strategies can change, besides
individual commitment
Rossen: Every time we've made progress on SVG it's when a core set
of us who sat around a table. That was shans, TabAtkins -
both CSS. dino was involved. Most things changed and moved
was those overlap meetings.
Rossen: In terms of making process I believe we have the core
expertise and right set of people in the WG.
Rossen: With the commitment of BogdanBrinza and whoever else
commits I'm hopeful it will happen quickly.
<SteveZ> The W3C Process does not say that you MUST deliver, only
that you SHOULD deliver or declare that no further
progress is possible and publish a Note to that effect.
Florian: If we have the motivated set of people, why is that not
it's own WG? Why is the merge needed? The same people can
be in multi WG.
<fantasai> thinks what's needed is someone who is willing to take
ownership of the issues list and agenda
<fantasai> we needed that for 2.1
<fantasai> including testing issues
Rossen: I'm not sure if plh is on the phone. If this is supposed
to be its own group isn't something we can decide. We were
asked to help and I'm relaying it.
BogdanBrinza: I think the proposal of the plan and timelines are
something we want to have. I want to approach this
the way we do software development.
ChrisL: I had two things to say. We have the a11y TF which I think
has Rick on it who was part of SVG. During the previous
review of SVG WG charter which failed there was a comment
from Mozilla that maybe this should be in the CSSWG.
<tantek> Thanks ChrisL for passing along the Mozilla comment
fantasai: Why did charter fail?
ChrisL: No implementors stepped up to join. I don't have it in
front of me. It was below critical mass. There needs to be
at least 24 responses.
Florian: The other aspect is the proposed charter was a death
march to ship REC within a year, which killed enthusiasm
for Invited Experts.
ChrisL: Yes.
Rossen: This is one way to put it. The other way to put it is it
wasn't a march to death. It was to scope down and ship a
spec that was worked on for 13 years and had no progress
until a year or two ago.
Rossen: Proposal was centered on keeping that focus and shipping
the spec and chipping things away to other groups.
Rossen: This was just an introduction. I'm sure more discussions
will happen. THis was a conversation starter.
<tantek> When no browser implementers support a WG producing
browser technology, the WG must not be created/renewed to
avoid the XHTML2 failure mode
<Florian> The spec is longer that css2.1, does not have a test
suite, and was chartered to reach REC in Q3 2017. This
was a death march, I stand by my words.
<Florian> For the record, in relation to the earlier SVG
discussion, I've checked my ac-forum mails, and I cannot
find any announcement of the charter review failing,
from plh or anyone.
CSS Alignment
=============
<fantasai> https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-align-3
fantasai: We can go either way on the open issues. The last
baseline alignment with scroll boxes need more thinking.
Should `align-self` and `flex` (& its subproperties) be honored on
table wrapper box?
------------------------------------------------------------------
<fantasai> https://github.com/w3c/csswg-drafts/issues/547
fantasai: We had text in the past and lost it during an edit that
said if you apply flex and align-self property does it
apply to table wrapper box.
fantasai: If people are happy we can make changes.
fremy: I'd prefer this in table spec, not align. I'm fine with the
idea, but I don't think it goes in here.
fantasai: This would go into align in terms of what the property
applies to and also the flex box spec.
fantasai: It's a bigger topic, but the distinction between if
things apply to table wrapper box applies across all of
CSS and we should be careful to note it.
fantasai: There should be a systematic way to track that and it
should be noted in that property or else we'll forget
stuff.
fremy: My opinion is different that we should have a clear rule in
the table spec and not decide on each property.
fremy: I think nearly every property in CSS instead of making a
list of them, instead create a rule in the table spec.
fantasai: In terms of flex specifically it requires explaining how
it applies. Flex applies in that the table wrapper box
needs to be flexed to match the calc in flex. It's
complicated in this case.
fantasai: Since flex is further along and tables is in 2.1 I don't
think we should leave it out of flexbox until tables is
in CR.
fremy: I'm fine. If we want to resolve and no one objects let's do
it.
Rossen: Going back. My first question is does anyone do anything
with tables when they are flex items currently?
fremy: Nope
Rossen: We don't. Playing with flexbox I don't believe other
implementations do. Everyone who has worked on table
layout knows how "fun" it is to make changes there.
Rossen: If this is an incubation question would anyone have
interest in implementing flex on tables? If yes we can
corner the spec somewhere.
Rossen: Mostly that's to other implementors of flexbox.
Rossen: I don't hear any.
fantasai: You don't have the flex impl on the call. This text was
in CR. It was lost during a change for anonymous boxes.
fantasai: It probably shouldn't have been.
<fantasai> https://drafts.csswg.org/css-flexbox/#change-2015-anonymous-fixup
lost text during a related change, in CR
fantasai: If we decide down the line we don't want to impl, but it
should be in the spec. It's reasonable to want a flex
item that happens to be a table to flex to take up the
space and not act fixed.
Rossen: You want to keep this in flex spec?
fantasai: I want to restore the text.
Rossen: I think it's fine. We can discuss actual merit later.
Rossen: Request is restoring the text in flexbox that spec that
tables as flex items respect flex.
Rossen: I encourage those not in favor of the behavior to open an
issue.
RESOLVED: Restore the accidentally removed text from css-flexbox
specifying how flex applies to table wrapper boxes
Last Baseline Alignment of Scrollable Boxes
-------------------------------------------
Rossen: Next issue is scrollable boxes and last baseline alignment?
<fantasai> https://github.com/w3c/csswg-drafts/issues/766
fantasai: CSS align had a sentence that [reads]
fantasai: CSS2.1 had a different sentence [reads]
fantasai: There was an issue raised on 2.1 to make overflow have a
less dramatic effect by honoring baseline of actual text
unless the actual text overflows.
fantasai: I looked at the 3 versions and I wasn't sure if the one
we resolved on was right. The text in CSS Align seemed
the most useful. I want to hear other thoughts.
fantasai: We need to move 2.1 into align or vice versa.
myles: As far as I know there aren't any impl that follow this
feature of CSS align so I'd be worried about changing
behavior for every impl.
myles: Seems that one of the existing behaviors should be
reflected rather than making every impl change.
fantasai: Seems reasonable.
Rossen: I'd be in favor of myles' approach as an impl.
Rossen: Anyone else? If not we can resolve.
myles: One other piece. What is the reason that CSS align says
this?
fantasai: We had to define differently between how you find the
baseline of the box...when you take the baseline from
the text you need a scroll position. The scroll position
for using first baseline is straight forward. Last
baseline problem is that you are trying to align to
something that is overflowing and that's not useful.
fantasai: For scrollable boxes we defined last baseline you scroll
to the final position and take that. When you've
scrolled to the bottom you're in alignment. In 2.1
there's no way to align to that. That makes a difference
when trying to align to something scrolled all the way
to the bottom. There's no way to get that to baseline
align outside that box.
fantasai: If we take CSS Align that you scroll to the final
position and then it'll be in view you can use that
bottom edge and align that to content. Like if you're
making a chat app you would care about that as they
scroll upwards and you tend to hang out at the bottom.
fantasai: I don't think we thought about that when creating 2.1 I
think this behavior gives a useful result instead of
semi-random result.
myles: Yeah. I'm just worried about every browser breaking web
pages.
<tantek> wonders if there is a test we can check for that
<fantasai> tantek, what do you mean?
<tantek> for breaking every browser - is there a test?
<tantek> just wondering if there is an evidence based way to
resolve this issue, instead of "what should happen" vs
"worried about every browser breaking web pages"
<tantek> myles, if you can produce a test that demonstrates the
"every browser breaking web pages" for this change, then
I think you'll get more support :)
Rossen: Anyone else?
Rossen: Let's try to resolve. Would that mean we remove this from
CSS align?
fantasai: It means it changes its text to match 2.1
fantasai: There's 3 behaviors.
<fantasai> A) (original) if 'overflow' is not visible, use the
bottom margin edge, ignoring the contents
<fantasai> B) use the last baseline, but if overflow is not
visible, then clamp that to bottom margin edge
<fantasai> C) if overflow is not visible, scroll to the bottom
then use the actual baseline
<fantasai> Note: this is for aligning to the *last* baseline
Rossen: I would caution here that this may or may not have side
effects to intrinsic controls. So an input type text in
our implementation is a div with an overflow: hidden and
we do align baselines of controls with rest of the lines
given they're positioned in an inline context.
Rossen: That definition of being an overflow or not seems a bit
too restrictive from that POV.
myles: So form controls are inline blocks?
Rossen: Yes. They can get any type of display.
myles: Which of these are you commenting about?
Rossen: B
Rossen: [reads]
Rossen: Again, if I re-iterate the input-type:text is
overflow:hidden and we can perfectly well align with the
baseline inside. Some thing goes with text area. We can
align on the line inside a text area. When people create
components I would expect the normal pattern to be try and
encapsulate them as much as possible. If we lose the
ability to align with the baseline it would be unfortunate.
fantasai: I think what we're ending up on is that A or B would not
allow you to create a component that allowed you to
align with the last line. Here's a test case with a
select box.
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3E.A%20%3Cselect%20size%3D2%3E%3Coption%3EA%3Coption%3EB%3Coption%3EC%3C%2Fselect%3E
<fantasai> with margin:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3E.A%20%3Cselect%20size%3D2%20style%3D%22margin%3A%201em%22%3E%3Coption%3EA%3Coption%3EB%3Coption%3EC%3C%2Fselect%3E
fantasai: CSS 2.1 with or w/o myles proposal says if that's a div
you would align to the bottom margin edge, not the text
inside. To align to the text inside you have to account
for it. And the text in the align spec will do that.
myles: In your form controls if they do overflow do you do the
scrolling behavior?
Rossen: None do.
Rossen: I was just using the example of intrinsic controls because
it's simple. When we generalize to components I would
expect them to be more encapsulated then not.
Rossen: Even though we have full control behind the scenes for
intrinsic, I don't believe we'll have that for components.
I want to make sure we're not cornering ourselves for web
components.
myles: It sounds like if we're going for most encapsulation it
should always be the border box and no one wants that.
Rossen: I agree we don't want that.
myles: Aiming for more encapsulation is not sufficient to guide
this decision.
Rossen: It's sufficient to exemplify why A and B are less then
ideal.
fantasai: I'm going to say this needs more discussion and we
should think on use cases and comment on the thread.
Rossen: I'm fine with going back to github.
Publication
-----------
Rossen: Publication. I don't know if this includes that.
<fantasai> sorry, fell off
<fantasai> No, just want to update.
<fantasai> Can update more after we resolve this :)
<Rossen> so you're OK if we don't pub now?
[wait for fantasai to type or rejoin]
fantasai: We want to update the spec. WE can update more after
issues are resolved. It'll be the first echidna update.
<tantek> ship it!
Rossen: Objections to republishing?
RESOLVED: Republish CSS Align CR.
Rossen: fantasai please work with the contacts to publish.
CSS profiles in future snapshots
================================
Florian: There have been a couple of snapshot issues. One I want
to mention is it refers to CSS profiles even though the
docs are abandoned. WHat should we do about the profiles
and about the snapshot?
Florian: fantasai pointed out others refer to them
<tantek> We can OBSOLETE them as of March 1 per the new process!
<fantasai> tantek, they're not obsolete. They're just inert.
<tantek> uh, inert sounds like obsolete :P
<fantasai> obsolete is "we don't use this spec anymore, we have a
better spec here"
<tantek> fantasai - no, obsolete is - do not implement. nothing
about "better spec here"
fantasai: Other standards organizations point at these profiles.
We froze them as notes and said no further work. They
have not been rescinded. There's no reason to. So I do
think they are part of the snapshot because they're work
we did here. Unlike other work where we've said we won't
continue.
Florian: Not taking down the profiles, fair enough.
Florian: They are wrong, though. The one about TV says you may
support all media types, but you must support all and TV.
TV has been deprecated so if you support it you'll do
something incorrect. We shouldn't point to them because
they're wrong.
fantasai: They're still...though TV is deprecated anyone following
the standard is going to follow it. There's deprecated
technology, but anyone working with those old tech need
this. We're not recommending to use them, but we're
saying if you need them they're here.
Florian: For example, when we deprecated we didn't say don't use
it, we changed it to does not work. The spec says it must
never match anything. The profile says if you're a TV use
that. Pointing to them ourselves seems like it would lead
to confusion. From the snapshot it seems odd.
tantek: These aren't TR?
Florian: They're notes.
fantasai: That is TR.
Florian: TR notes.
tantek: Notes makes it less of a big deal.
tantek: If we think they're broken we should mark obsolete.
Florian: I haven't read them all, but I read the beginning of one
and found something wrong. It made me concerned.
tantek: If they're out of date we should mark as do not implement.
Rossen: We can add the red banner. Are all the profiles wrong?
Just TV? If we don't know we can go through and decide.
Not on a call.
Florian: No one wants to go through. That's why they're out of
date.
Rossen: One was published on Oct 2014...mobile.
Florian: By that measure they're all fairly recent.
Rossen: We can take the opposite. Let's add the note and if
someone who does care they can go and read them and
propose changes.
Florian: Yeah. I think we need to phrase carefully, but a warning
is appropriate.
Rossen: Can't we use the regular warning?
Florian: How does it read?
Rossen: [reads]
fantasai: That's not appropriate,
fantasai: If you want to mark obsolete you can.
Rossen: ChrisL? Can notes be obsolete?
ChrisL: Obsolete is about recs.
SteveZ: The obsolete thing is for things the AC has approved.
Notes don't require approval.
tantek: He's got a good point. We don't need to follow the full
procedure, we can just do a warning.
fantasai: "this spec is obsolete and not maintained"
Florian: And having in that note a link to the snapshot saying
this is a good place to look makes sense to me. Having
the snapshot point to them makes little sense.
tantek: I'm fine with that proposed note.
Rossen: Let's try and capture this. Objections to adding a warning
note to all profile notes (mobile print tv) saying they
are obsolete and if people want to see what the WG is
doing they can go to the snapshot
RESOLVED: Add a warning note to all profile notes (mobile, print,
tv) saying they are obsolete and if people want to see
what the WG is doing they can go to the snapshot.
ChrisL: Should we point to snapshot or /TR?
fantasai: That is the snapshot
ChrisL: I mean to /TR/CSS/ which points to snapshots
<tantek> fine
Rossen: Sure.
Rossen: Do we need to contract anyone else that has a dependency
on those notes?
ChrisL: It was external organizations I think. I don't think
anyone in AGB did TV. It would surprise me if anyone in TV
was paying attention to it.
<tantek> ChrisL it wouldn't surprise me because Mark of Netflix
was complaining about out of date specs on TR just last
May
<tantek> and Netflix does have something to do with TV ;)
Florian: The resolution I wanted was to stop linking to them from
the snapshot
Rossen: objections?
<ChrisL> +1
<tantek> no objection
RESOLVED: Stop linking to obsolete profile notes from the CSS
snapshot
Rossen: Thanks everyone.
Received on Thursday, 9 February 2017 01:30:02 UTC