See also: IRC log
<dauwhe> Bonjour to Zakim, RRSAgent, and trackbot
<fantasai> ScribeNick: fantasai
gregwhitworth: Issue wrt replaced elements as table cell
<gregwhitworth> https://github.com/w3c/csswg-drafts/issues/508#issuecomment-317529294
gregwhitworth: We added a diagram of what the spec says to do
<dbaron> github: https://github.com/w3c/csswg-drafts/issues/508
<gregwhitworth> https://github.com/w3c/csswg-drafts/issues/508#issuecomment-260486721
gregwhitworth: Made a table of
results
... what we tried to do, where it behaved more like block,
specified to be as block
... if behaved more like inline, specified as inline
... we dont' have a strong pref
... This is 1st to discuss
dgrogan: WE talked about this in Chrome, don't want to defend our behavior. I todesn't make much sense
gregwhitworth: For firefox, we
prefer firefox behavior
... It seems like author did something wrong, so make it more
obvious it's wrong
dbaron: One question here is do you do anonymous box construction around these things
gregwhitworth: ... no
dbaron: Do you think some of these results are because of anonymous box construction?
gregwhitworth: they don't create separate cells
fantasai: They wouldn't, if they did anonymous box construction ...?
gregwhitworth: ...
... So besides Chrome having pref, anyone else?
Rossen: So path forward is to fall back to Firefox's behavior?
fantasai: Seems to me that making it block would make more sense
fremy: Wouldn't be Web-compatible
gregwhitworth: Any objection to resolve on Firefox's behvaior?
RESOLUTION: All internal table displays on replaced elements to behave as 'inline'.
RESOLUTION: table falls back to block, inline-table falls back to inline
tantek: Point about anonymous box construction, are there tests ?
gregwhitworth: I'm sure we have tests for it somewhere
tantek: ...
fantasai: What do you mean anonymous boxes don't get constructed?
dbaron: Do individual things
create individual table cells, or group together into one
cell
... Do different things depending on row-group vs table-cel
etc
tantek: Based on what dbaron said, maybe just copy what Firefox does
<Rossen> The resolution is specific about what the behavior is
fantasai: If it's defined as "behave as inline", then anonymous box construction is defined
dbaron: Could do anonymous box before, rather than after treating as inline
<Rossen> ... and it is not "just repeat what Firefox does"
fantasai: That would end up with improper table structures, which the spec does not allow
<dbaron> github: https://github.com/w3c/csswg-drafts/issues/607
fremy: Next issue is min-width and percentages
<dbaron> https://github.com/w3c/csswg-drafts/issues/607#issuecomment-317532741
fremy: width behaves as min-width
on tables, so it's a bit redundant
... Browser generally ignore min-width of percentage, except
Firefox
... Would like to ignore percentages
dbaron: Would like to explain why
percentage on min-width overrides width
... That's the general behavior of tables
... If a column has cell that's a lenght and cell that's a
percentage, it ignores the length instead of the percentage
fremy: We should go with the more interop solution
fantasai: What about fixed tables?
Rossen: What would be different?
fantasai: widths aren't
"minimums" in fixed layout, they're honored and the content of
the cell doesn't matter
... I would expect min-width and width to interact as for
blocks in that case
<Rossen> Fixed layout for table cells is the same as in normal
<Rossen> the only difference is that the overall column sizing and distribution is based on the first row only
fremy: Our goal was to spec most
interoperable behavior
... So we should go with the non-Firefox behavior
fantasai: But what about fixed tables
Rossen: You do the layout based on the first row
fantasai: ...
dbaron: fantasai is saying that in fixed table layout, you honor the width even if the contents overflow
fremy: It's true content
overflows even i nthe first row, but that's not the
problem
... But if you have a table and you set 300px on the table and
100px on the two columns, then you get 150px columns
fantasai: but we're talking about a different case
<Rossen> https://jsfiddle.net/gvco0t54/2/
fremy: min-width % on fixed tables is ignore
glazou: Is your goal only interop?
fremy: Yes, all browsers except Firefox ignore the min-width
glazou: Yes, but you haven't considered the user's perspective. From the perspective of the Web author, why would you ignore min-width percentage only on these elements?
fremy: I don't think there's a
strong reason, except this is what browsers do.
... No good reason not to do it, except we have multiple
impls
glazou: Web browsers can be
wrong
... It's not all browsers, there's at least one that implements
it
astearns: It's been here for decades
glazou: It's been in Firefox for decades too
dbaron: We do get requests from
authors to make these things work in tables
... e.g. we get requests for max-width to work, but that's a
bit harder
... It's weird to try to honor web author requests for new
features, but here where we have the feature they want, we
decide not to have it because it only works in one browser not
four
Florian: we have evidence that the Web doesn't break if you don't support min-width, but we also have evidence that it doesn't break if you support it
gregwhitworth: The only reason
we're working on this spec is because we'll try to fix a bug
and other sites will break
... I guarantee you that there are websites that are broken if
3/4 browsers have interop
fantasai: ...
fremy: In tables widht works like
min-width
... The author doesn't lose anything here
... I don't buy that we are bothering authors, if you want to
use table you would learn to use width
fremy recites history of widths
and HTML
glazou: The problem is with "authors should learn CSS'
gregwhitworth: Your assertion is
also that authors should test in Firefox, and we know they
don't
... We put opening in the spec, ..
... 3 browsers are shipping this way, that's the de facto
standard
fantasai: ...
fremy: ... doesn't work
fantasai^: You have to consider what browsers do but also what makes sense.
fremy: min-width and widht are just widths
fantasai: except in fixed tables
dbaron: I guess I'm OK with this, but please add tests to WPT
glazou: I can live with it, but I find it regrettable
Rossen: Proposed that min-width: % is ignored on table cells
RESOLUTION: Ignore percentage min-widths on table cells
<gregwhitworth> https://github.com/w3c/csswg-drafts/issues/474#issuecomment-317544515
fremy: Bit of history
... 1st issue is that Firefox for a long time had very
different usage for height on table cells
... Height on table cells was applied on table cell not on
row
... But earlier we resolved that height on table cells is
applied to th row
... That change was not made in Firefox
... For that reason, firefox does very different resolution of
% on table cells
... All other browsers have similar behavior
... Which is 1st computation of layout, cell doesn't have any
size, so % is treated as auto
... Then you do a 2nd layout pass
... In this case, all browsers will apply the percentage based
on size assigned to the row
... Which is also assigned to all cells in the row
dbaron: Is it interoperable when you do the 2nd pass and when don't bother with 2nd pass
fremy: We always do 2nd pass when there's a %
dbaron: that's not what I found
fremy: Testcases we wrote gave
identical results
... One exception unfortunately
... In Chrome, if you set overflow: scroll on an element
... Rule in CSS, if size is auto and you're allowed to scroll,
automatic size is smallest size possible such that you don't
need to scroll
... That's in general for CSS
... This is what edge implements
... But not web compatible, because this is not how it
works
... In that case, in the 1st pass the auto sie is considered
0px
... So in 2nd pass you are going to have a scrollbar
... The scroller will match the size of the rest of the cells
in the row
... In Firefox, because you resolve percentage based on the
height set on the cell, you get exactly the same behavio
... because 1st pass in Firefox, you already know your
percentage
... Edge is outlier, because we don't give the same
behavior
... So we propose that we match Chrome behavior, because Web
interop requires it
... Canonical example is ToS
... People set height 100% on scrollabe ToS, and then button to
accept in the next row
... In Edge the 1st row blows up and gets as big as needed to
contain entire ToS
... So we would like to resolve on doing what Chrome is
doing
... If you're allowed to overflow, your automatic size will be
0px
fantasai: And that's for a table cell?
fremy: Percentage is set on the child
of the table cell
<dbaron> second testcase in https://dbaron.org/css/test/2006/percent-height-in-tables
dbaron: You claimed that you
always do 2nd pass, so I loaded testcase and loaded in
Chrome
... And I got as far as the 2nd testcase in the set before
finding a contradition with your assertion
<dbaron> <table border><tr>
<dbaron> <td><div style="height: 25%">25% height div</div></td>
<dbaron> <td>text</td>
<dbaron> </tr></table>
fremy: % doesn't get
applied
... % inside auto container is ignored
dbaron: Except that's not how it
works in tables
... there are things in tables that can make things non-auto
height, that don't match that CSS rule
fremy: Rule in CSS is extended in
css-tables-3
... You need at least one table element with a height
defined
... that isn't a percentage
dbaron: If you define height on table itself, then ...
fremy: "It is appropriate to
resolve percentage heights on direct children of a table cell
if the cell is considerd to have its height specified xplicitly
or the child is abspos, see CSS2. It is futher clarified that a
cell is considered to have its height specified explicitly if
the computed height of the cell or any of its table ancestors
is a length or percenage and that length does not "behave as
auto""
... Cases where we don't have interop are on tbody we don't all
behave the same way
... but agreed we'd behave the same way on tbody, so fixing
that issue every browser should behave the same
Rossen: Interop with firefox?
fremy: Firefox has a different model
dbaron: We have tests if any cell
in a row has a specified height
... The code that decides whether hegihts are definite looks at
whether there's any cell in the row that has its height
specified
... So I wouldn't blow that all off as having not implemented
that decision
Rossen: So what is the proposed resolution to this issue?
fremy: the stuff I just
quoted
... "During first pass, percentages are resolved as auto,
except if they are height-related and used on a scrollable box,
in which case they resolve as 0px. Edge changes its behavior,
as well as Firefox once it fix the other bug."
https://github.com/w3c/csswg-drafts/issues/474
fremy: To explain behavior in
dbaron's testcase
... ...
... Like other places in CSS, you don't apply percentages if
you're in auto height. For tables it's more complex, looks at
table ancestors
dbaron: Is this also
interoperable when tables are paginated for printing?
... Because I know that the behavior is dfiferent when tables
are paginated.
fremy: I haven't tried printing
tables...
... Why would it be different?
dbaron: Shouldn't be but in Gecko it is
fantasai: Consideration for printing, maybe. When printing you can't scroll, so if you can size the item to show all its content that's better.
Rossen: So should we resolve?
dbaron: I'm still trying to
understand some of these cases...
... I'm okay with resolution for now, if I think it's wrong
I'll reopen
Rossen: Objections?
RESOLUTION: Accept proposed resolution for #474
dbaron: afaict, 1st testcase that I found a difference between FF and Chrome is where FF does what you say and Chrome doesn't
<dbaron> <table border><tr><td>
<dbaron> blah<br>
<dbaron> <div style="height: 50%">hello</div>
<dbaron> <table style="height: 50%" cellpadding="0" cellspacing="0"><tr><td>hello</td></tr></table>
<dbaron> blah<br>
<dbaron> blah<br>
<dbaron> </td><td height="200"></td></tr></table>
dbaron: There's an outer
table
... Inside of it there's two cells
... 2nd one is empty but has explicit height of 200px
... In your model means row has 200px definite height
... other cell has ...
... In Gecko, we honor the height 50% on the div
... and also on the table but the table overflows the cell
(??????)
fremy: There is no reason for a table to behave differently from a block here
dbaron: So the thing we just
resolved on is not what Chrome and Edge do
... matches Firefox better
... Which I'm okay with :)
... testcase is the 2nd one after the horizontal rule
...
fremy: You look for a definite
height on the ancestors
... ? does not apply
dbaron: ...
... ok whatever
<gregwhitworth> https://github.com/w3c/csswg-drafts/issues/484#issuecomment-317943064
gregwhitworth: Doign excess width
distribution of space
... Edge and Mozilla render the same
... We do same distribution as non-fixed mode
... We wanted an actual resolution
... Chrome team said they're ok with the change
dgrogan: we're okay with caveat that we check web compat data
gregwhitworth: Talked about this
at TPAC
... Specified Edge behavior currently
... To not get rid of data
... But when author asks for visibility collapse on column or
row
... They've asked that row or column to be gone
... If you have a spanning cell that goes into the collapsed
column/row, then clipped to visible columns/rows
fantasai: I think that's what's in the spec. Not really that great
gregwhitworth: FF overflows the
content
... Behind a flag in Chrome
dgrogan: We also clip to border box. Behind a flag
fantasai: I thin there were two
options we were considering here, and overflowing was
definitely not one of them
... ...
dbaron: This would ...
<gregwhitworth> https://jsfiddle.net/v23h0338/
gregwhitworth explain the demo
dbaron: Suppose before collapsing
ou have a cell here and it's part of 3 rows that are
conceptually here
... cell has some content which overflows in theses various
directions
... And then you collapse the middle one
... When it's not collapsed, these overflow visibly
... Are you saying when its collapsed, we only draw...
... I'm collapsing the middle row
gregwhitworth: You only draw what's in the first / third cells
[drawing on whiteboard, behind Bert, can't be captured for minutes]
fremy: If you're clipping the middle row, do you draw the content in the 1st and 3rd rows, or do you show the 1st and 2nd rows and clip out the end
dbaron: Once you collapse the middle row, you're clip everything that overflows the top and you're clip out stuff [over there, over there nobody is telling me what that means and I can't see it]
gregwhitworth: This is an edge
case
... Haven't seen people hiding rows/cols except in data grids,
and ...
... What you're proposing is complicated
dbaron: If it's not a use case why clip anything?
Rossen: That is the use
case
... Your primary purpose was to have a layout
... We go to extreme lengths to avoid overflow
... To make sure that all content is displayed inall
cells
... Then you have user facing behavior that allow ppl to
collapse things away, purposefully make things appear or
disappear
... When they explictily aske for something to disapear, and
you continue to show them what disappeared, weird no?
dbaron: I just meant don't clip this cell
gregwhitworth: In dbaron's example ...
<gregwhitworth> https://jsfiddle.net/dgrogan/9uduq99L/3/
gregwhitworth: If you
collapse
... we end up clipping in both axes
... My statement ot dbaron is, he forcefully asked for no wraps
which will overflow
... I don't see circumstances where it isn't primariy the
excel-based scenario
... this is the most performant way to accomplish, which is
clipping to bounding box
... weird side effect
dbaron: Proposal is that if you
have a cell that spans some collapsed rows or columns
... that cell clips its content to its resulting bounds
gregwhitworth: yes
RESOLUTION: cells spanning collapsed rows/columns are clipped to their resulting bounds
(in both axes)
Rossen: Goal of work on this spec
is to minimize interop pain
... not trying to rewrite history
... issues aren't introduced, we're trying to write out the
path of least resistance
https://lists.w3.org/Archives/Public/www-style/2016Nov/0069.html
<eae> ScribeNick: eae
gregwhitworth: I was planning to
have this discussion with Geoffrey and Tab at some point.
... When we were working through table tests I was going
through all anchor tags to get an idea of test coverage.
<dbaron> Gecko bugs on implementing the results of our previous discussion on tables: https://bugzilla.mozilla.org/buglist.cgi?bug_id=1386981%2C1386982%2C1386983%2C1386985&list_id=13708350. If it's not in that list, I don't know about it.
gregwhitworth: It was pointed out
to me that I can't depend on the anchor tags as they change for
various reasons
... Basically from what I could see there is a fundamental
problem, we're waiting until CR until doing a review of all
tests
... We need to keep these things up to date as we go
... We could add an automatic solution, maybe in
bikeshed.
... We could either anchor any line or sub anchors.
... Espeically for things like MUST and SHOULD
... We need to resolve normative changes that have
corresponding tests.
... Would slow down the process.
... When you make a change include a test collateral. Two
action items: 1) For normative changes to coincide with test
collateral. 2) some kind of work to bikeshed to aid in
this.
... To prune as we go. Additionally worth considering that all
specs would have a test QA editor
... We've seen the benefit of this at Microsoft.
astearns: When you went through the flexbox tests manually did you find that the anchor tags where not sufficient
gregwhitworth: Too broad. Requires reverse engineering to find the right section.
astearns: For prior art, in terms of more specific anchor. You might want to take a look at the WOFF spec. Has anchors for all.
TabAtkins: Very easy to do in BS. Wrap everything in an assert tag.
fantasai: Specs do change and the individual sentences that are associated with a particular test isn't stable. Automated association will result in broken links.
TabAtkins: Manually associating isn't practical either
astearns: If automated we cna show that this anshor change, anything associated with it must change. Automation can give us a checklist that is a subset rather than a full set.
dbaron: The actual assertion often brings in other defintions.
gregwhitworth: I agree, you
cannot fully depend on this to solve our tesitng needs. We need
to resolve that when you make normaitve changes there is also a
test change.
... I want to be able to run the test suite to know what
changed.
astearns: You claimed this would slow down the process. I don't think this is true. You had to manaully do this for flexbox, if we can automate it it might be faster. Would speed up feedback for changes if it came with tests.
Florian: Not sure this is true,
it takes at the very least many months to get anyone to take
review.
... For mutlicol for instance it might take years for the
review.
<fantasai> Florian^: Maybe for high-priority specs like grid or flex, you get the review quickly, but
Rossen: The problem is from what
I have observed, a spec goes through an idea phase, someone is
excited. A lot of people are talking about it then disucssion
starts in the domain. Veyr few people are participating in
topic. Then we get to bikeshedidng names, everyone is involved.
This is the best part. Then we're in a no-mans land where we
want to start implementing but there are no tests.
... This is the part where nobody wants to participate.
... Then we have someone who starts implementation.
... If there are no tests that are there to verify the
asusmptions. Then we start making up our own assumptions. Then
when the next implementor comes along there are a lot of
interop issues.
... Then we find ourselves here a few years later wondeirng
about min-width for table cells, for instance. This happens
when the test was written as a part of the implemtation.
Florian: I want tests. I like
tests. I write a lot of them. And I harass people to review
them.
... People *should* write tests with spec chnages, yes. I
agree. Requiering tests for all changes, maybe not so much.
Would slow down process *a lot*.
<fantasai> Florian: I wrote a bunch of UI tests, fantasai finally reviewed them a year later after I ambushed her after dinner last night.
dbaron: A bunch of specs at the whatwg, about 3-6 mo ago tried to do more test driven. Feedback form that is that they're moving faster than before.
gregwhitworth: Florian, I think
that is a valid point. Important that when we sign up for a
spec we're not only signing up for the spec, you are also
signing up for tests as well.
... If no-one wants to sign up for QA then that is a
problem.
... It's fun to work on spec. Not as fun to review test changes
or star writing tests.
... Important that the QA people are here as well.
fantasai: One advantage of QA not being here is is that if the spec is not clear then the QA person cannot infer from discussion. Validates that the spec is clear.
Florian: We should assign people
to be in charge of the test suite. Hard to find
volunteers.
... If we're explicit about ownership we'll see spec that lack
a QA owner
<fantasai> (That said, i'm all for having more QA involvement in this process. We've historically had that back when Opera and Mozilla had dedicated QA persons, and we've lost that along the way.)
Rossen: We started three months
ago to move a nch of specs that we belive as a working group to
be close to rec. Fonts, for example, was one awesome example of
a spec that got a lot of attention. A bunch of tests added to
it. Reviewed. This spec is now moving very quikcly compared to
other.
... On the other hand, we have background and borders, needs
tests from mozilla.. Cascade-3 needs tests from mozilla.
... Two more specs where we are waiting for tests. Specs that
have been in the works for years. Specs that are already
implemented and have been for years. Holding us back. We're
missing tests. We don't even have the data to start the
discussion around whether we're interopable. Holds up the
process.
... Those specs, that could have been recs, arguably years ago.
Will not be rec for years to come due to lack of tests.
fantasai: We need more dedicated
QA. We've had that in the distant past.
... We don't really have that as much as we need. We have Greg,
wokring on some stuff, Florian is working on some tests. Japan
doing it for writing mode. Only a little bit here and
there.
... Having we and Tab and I having QA ownership for everything
is not scalable nur reasonable. Need more people involved.
Rossen: This is correct.
... You (Tab + fantasi) are not the only ones who should be
doing this
glazou: This is a really old problem/. We're all implementros here. Some people do not consider it as rewarding. We've always had this problem where we've relied on the work of ???.
fantasai: We've not always had this problem. Years ago we had people that were interested in this.
Tab: We should make daniel the QA owner for all specs :)
glazou: Any decision made here relies on the commitment from corporate members of this group to dedicate participating engineers' time to write tests FOR THE WG, which they don't atm to commit resources for testing to this group, not just send people to work on specs and implementations.
<fantasai> +1 to glazou
Rossen: I agree this is an old problem. Not the easiest to solve. I think most implementors companies have solved this problem years ago.
glazou: Internally.
Rossen: Internally. The spec writer knows how this is supposed to work. Commit your spec to an repo without review.
fantasai: that is what editors draft is for
<fantasai> (ED = repo without review)
Florian: If we have a resolution. We have a spec change, where am I allowed to commit that.
Rossen: As soon as someone starts implementing your working draft they will stare review your tests.
dbaron: They will look in web platform tests, not at unreviewed PRs. Do not like the review process
astearns: People will take the tests that are in web platform tests and run them. Will onlky review if there are errors. I think that is fine.
fremy: We mentioned that spec
implementros dont have time to write tests. Might be fair
... At the very least we know what tests needs to be written.
That needs to be part of it. "We need tests for this". At the
vert least that way two years later we'll know.
... That should be the responsibility of the spec writer
<glazou> +1 with fremy but that's theory ; I'm afraid practice will differ a bit
fremy: If the assertion changes,
that should be part of the spec process. Flagging tests that
needs to be changed.
... Otherwise impossible to know which tests needs to be
written for a change. Should be part of resposnibility for spec
editor.
... Nobody is in a better position.
<astearns> +1 to the idea of tracking what tests are needed, but issues in the test repo isn't the way to do it (we just threw out a bunch of issues that tracked this when we did the wpt merge)
fantasai: The person making the change might think of 20% of the needed tests, but it's better than none, yes
gregwhitworth: I feel like for
normative changes I don't think it is too much to ask that a
test case should already be written. Maybe you don't write 700
of them to cover all edge cases.
... We have a lot of people that want to be involved.
... For addative css for instance, who is going to wirte all
the tests?
... The goal is interop. Webdevs wants it to just work. That is
why tests are important.
... Some type of tests commitment for normative changes is
important.
<fantasai> gregwhitworth^: Have a QA owner, so when spec owner makes a change says "hey, can you write some tests for this thing / update the tests for this thing" (goes above goal is interop line)
glazou: Just one point about normative changes and tests. If we have a test for ??. In my opinion we need to wirte tests from the very beginning.
fantasai: Disagree. Some of the specs Tab and I have worked on have changed so much that writing tests from day one would have been a huge waste/ :p of time.
glazou: Hard to catch up if we don't have tests from the beginning.
<glazou> so many FPWDs already implemented and shipped w/o tests
<glazou> and used in the wild
Florian: If we're saying that there is an expectation to ahve tests for normative changes I'm all for that. Adding ecplicit resposnability I'm also in favor. On the other hand I'm against a policy that would disallow changes without tests.
gregwhitworth: When we get around
to CR, here are four hundred PRs. Test cases exists.
... There needs to be automation so that we're not trying to
puzzle it together years after the fact.
<Rossen> a?
fantasai: Resolutions that aren't followed more than 80% of the time aren't great.
<tantek> Is there a timebox or goal for this topic?
fantasai: We already have quite a few edits that don't make it into the spec until a year later. Wouldn't want to add to that.
Florian: We're already being slowed down for this. I've already considred hiring people to review my tests.
Rossen: Let's see if we can get
to something a little bit more actionable.
... 1) way forward, automation between tests and linking tests
from specs.
... What would be changed if a normative hting changed with a
PR.
fantasai: Would require an assert
tag around each part they change in a spec for bikeshed tooling
support
... We could make it a habit to wrap all things in assert tag.
Would be a bit annoying. Could help but we would end up with a
lot of broken links. OK wit someone trying this on one
spec.
... We should experiment with a couple of different
approaches
Florian: Our system could detect when we make a change to a section where there are no tests then somebody needs to know.
Rossen: Do we have a candidate spec for this?
<astearns> more-specific assertion tagging might be something to add once a spec is in CR (or late CR)
fantasai: You said we should have
q QA person for a spec. Lets take three specs and assign a QA
person and have them pick different approahces. Some migt use
assert, another might use a wiki linking and see how it
works.
... I don't think we have a good solution. If spec were staatic
bikeshould would be oboivus solution. That is not the case
until they reach rec. We need to experiment and see what the
right level of automation and linkage is. Individual people
need to try somehting and see how that approach works.
... We need somebody to own the testing practice for a
spec.
... Someone needs to own it: "this is my spec, I need it to be
tested".
... Then the tooling will fall out from that. I've tried many
approaches and none are ideal.
Rossen: We have a ton of specs.
choosing two or three is not a problem. Finding the QA people
would be more problematic but a good idea.
... Won't volunteer people here but as a working gorup we
should resolve to do this over the next few weeks.
... We need people to step up and take test ownershpip for one
spec.
<fantasai> there's various examples for how we've tried to coordinate spec and test and test assertion. Comments or quotes from the spec in tests are one way. Annotations into the spec source are another way. Bikeshed auto-ID cross-linking is another way. An intermediary wiki that connects spec sentences with test assertions with links to tests is another way...
Florian: If they determine the best approach is to add tooling that they aren't themselves capable of producing.
<fantasai> we don't have an obviously best way atm
Florian: If I'm the owner for a test, can I task people with that?
Rossen: You can file a feature
request for plinss
... Greg, was there anything else?
gregwhitworth: I think we need to figure out the tests for normaitve changes requirement
fantasai: At CR it is a reasonable requiremnet. Prior to that, not so much.
<tantek> agreed with fantasai
gregwhitworth: My problem is that that is the situaiton wre're in with flex. We have a ton of tests, I don't know who wrote them. I don't know what tests are for each change.
fantasai: For CRs we have failry close tracking. We have a chnages list and for a spec like flexbox they're listed in the changes list with a summary, it wouldn't be too hard ot also include a link to the tests.
<melanierichards> my comment earlier didn't get minuted so: if, with a process change, not getting tests reviewed in a timely fashion slows down progress in a way that's noticeable/painful to other people who want that spec to move forward (not just the test writer), that could be a forcing function to get tests reviewed faster / more people committed to reviewing tests
Rossen: Are there any formal requirmenets for normative changes to include tests
fantasai: Yes
<fantasai> https://www.w3.org/TR/css-flexbox-1/#changes-20160301
astearns: In part of you (rossen) and me to enforce.
fantasai: In link posted, each change has an anchor, a summary of the change, link to issue generaitg change, a diff for the change. We could add anothre component that is Test: <bunch of tests>
Rossen: Yes
gregwhitworth: Yes but I dont want 500 tests there and having them all reviewed at the end.
Rossen: If we already have a resolution for requering test for a CR that is great. This week alone we already have a ton of CR changes coming. We'll watch very closely how that goes.
fantasai: When we prepare for a CR we could look at the change slist and see the tests.
Florian: I think I'm okay with this. Do we want it in the change list or the DOC.
<Rossen> Normative changes to CR or later stages of the a spec need to link to an existing or a new test case(s).
fantasai: Sometimes you have multipe comments for leading to a single change.
PROPOSED RESOLUTION: Normative changes to CR or later stages of the a spec need to link to an existing or a new test case(s).
<fantasai> Proposal is the Changes List for a CR links to updated or additional test cases for each change
Rossen: Normative changes to a CR need to include test case.
fantasai: the changes *list*, not
the individual changes.
... We require a list of changes for CR updates. Reason is that
it is helpful for implementros. Changes are less expansive and
easier to track
<fantasai> than in WD
RESOLUTION: Changes List for a CR links to updated or additional test cases for each change
<Florian> https://test.csswg.org/harness/results/css-ui-3_dev/grouped/filter/
<Florian> https://test.csswg.org/harness/results/css-ui-3_dev/grouped/filter/17/
Florian: Link to test suite results
<fantasai> astearns, Rossen, values and units is blocked on https://github.com/w3c/csswg-drafts/issues/434#issuecomment-310183908
Florian: Normative requierments
that do not have two or more implementations
... Think covergae is sufficient. One test per normative
assertion. Only 6 are missing for MUST. More are missing for
SHOULDs.
... We're getting there. Since it is six and not zero I'm not
pushing for CR today. Please fix them so that we can go to
PR.
... One of the things I have not verified coverage for is
direcitonal navigaiton properties. Implemented in presto and
TD
... There are some informal issues raised. Marked at
risk.
... Specifically, one thing we have already resolved on that
has been quesiton is whether we should stick to what we have
resolved on with regards to cursor.
... All the changes to cursor auto should be UA stylesheet.
Have filed bugs to blink about this, they filed bug back with
"are you sure?".
fremy: In edge, there are some
cases where we have things in the UA stylesheet. Also things
that are magic. Much better to use UA stylesheet, fies
bugs.
... If you want to change, it should be in the UA
stylesheet,
<tantek> re: https://test.csswg.org/harness/results/css-ui-3_dev/grouped/filter/ I would be strongly concerned with any test that fails in blink, edge, gecko, *and* webkit
<Florian> https://github.com/w3c/csswg-drafts/issues/1598
Florian: If you find cases where
it cannot be in the UA stylehseet and it isn't a known one then
please file a bug back.
... Can we close this bug (1598) as no change?
Rossen: Any objecitons?
RESOLUTION: Close 1598 as no change.
<TabAtkins> GitHub: https://github.com/w3c/csswg-drafts/issues/1598
<Florian> https://github.com/w3c/csswg-drafts/issues/1637
<Florian> github: https://github.com/w3c/csswg-drafts/issues/1637
<TabAtkins> GitHub: https://github.com/w3c/csswg-drafts/issues/1598
<dbaron> github-bot, end topic
github: https://github.com/w3c/csswg-drafts/issues/1637
... https://github.com/w3c/csswg-drafts/issues/1637
Florian: We have a statement in
the spec, text-overflow ellipsis should not affect dispatching
of pointer events.
... When you click the ellipsis the block that hosts it gets
the event. Not clear to me that the statement normatively
requires how the event is dispatches. Should it be dispatched
directly yo the element hosting it or the one ellided.
<tantek> tries to remember what he was thinking with this text
Florian: Leave level 3 somewhat ambiguous about how events are eing fired (but not that they *are* being fired) and be more specific in level-4.
tantek: It is better than before
Florian: Block with nested block, event to block vs in0between spans. Not iterop.
tantek: Are there any strong preferences about how it should work?
Florian: Firefox seems better.
fremy: Agree, edge should match Firefox.
eae: Chrome thinks it is resonable to./
tantek: Can we add a SHOULD here to capture the consensus?
Florian: Haven't worked out the implications.
tantek: It is already in issue
description.
... Resolve on that same phrase, without being overly
precise
... Sounds like we have rough consensus
... "dispatches the event to the ellided inline element"
... That is all it takes, add it as a should. Capture consensus
and keep moving.
... We have one impl and verbal agreement from other
vendors.
Florian: Normative change.
tantek: Not all normative changes need to go to CR
Florian: If we can do this without process changes that's fine.
tantek: We need to document ever change in the CR to PR process.
Rossen: No problem with that.
PROPOSED RESOLUTION: Clarify in level 3 that the UA should dispatch the event to the elided element.
RESOLUTION: Clarify in level 3 that the UA should dispatch the event to the elided element.
github: https://github.com/w3c/csswg-drafts/issues/1618
<fantasai> So the resolution was that the event is dispatched as if text-ellipsis was none
Florian: As a note, this is not in our spec, HTML is weird when it comes to image maps.
<fantasai> (fantasai asked for clarification on what the resolution meant)
Florian: The cursot that you are
supposed to use over an area in an image map depends on the
area element and not the image you are hovering.
... The only property that is affected by area is the
cursor.
tantek: I agree
Rossen: Other opinions?
<tantek> yes, add the informative note
PROPOSED RESOLUTION: Add informative note that links to the part of HTML that specifies how cursor works on image maps.
Rossen: Any objections?
RESOLUTION: Add informative note that links to the part of HTML that specifies how cursor works on image maps.
<Zakim> tantek, you wanted to discuss https://test.csswg.org/harness/results/css-ui-3_dev/grouped/filter/ I would be strongly concerned with any test that fails in blink, edge, gecko,
tantek: The tests results are really good, as pointed out by florian, there are a some we do not ahve tests for.
Florian: Directional navigation yes, I don't know.
<Florian> https://test.csswg.org/harness/results/css-ui-3_dev/grouped/filter/17/
tantek: In addition to the less
than two problem, there are numerous tests, ...
... Looking at the list there are several tests that have
failures across all of the edge/blink/webkit
... Indication that the normative text causing that needs
looking into before we go to CR.
<tantek> https://test.csswg.org/harness/results/css-ui-3_dev/grouped/filter/
tantek: If we're seeing four of
the major engines not do something that is a string indication
it should be downgraded to MAY
... If you scroll down to outline tests 14 & 15. Have three
of the four engines failing. No one esle supporting./ 8 - 14
all but one of them have all four engines failing it.
... Text overflow 18-19. Just talked about that
... Cursor image, 13-15. Visually obvoius
... Everyone of those where three enignes are failing, if these
are coming from MUSTS they should be dropped
... We shouldn't set the expectation that the SHOULD normative
secitons of the spec applies. Should be dropped or changed to a
MAY if we still think it is a good idea. Should as in
english.
Florian: Some of them are already MAY. Can't tell which are MAY vs SHOULD.
Action item on florian to see which ones are from SHOULD and consider whether to change to MAY.
<trackbot> Error finding 'item'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
Florian: Will cuase process churn.
ACTION florian to see which ones are from SHOULD and consider whether to change to MAY.
<trackbot> Created ACTION-856 - See which ones are from should and consider whether to change to may. [on Florian Rivoal - due 2017-08-10].
fremy: MAY is very open. Almost
seems like a bug we're expecting.
... We want to progress, may doesn't do that.
Rossen: Let's not discuss this now.
Florian: If we downgrade to MAY that would require a new CR
trackbot: Loosening conformance requirements does not necessarily require a new PR.
<trackbot> Sorry, eae, I don't understand 'trackbot: Loosening conformance requirements does not necessarily require a new PR.'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
tantek: Loosening conformance requirements does not necessarily require a new PR.
dbaron: Opposite of SHOULD is
SHOULD NOT
... Maybe it should be a SHOULD.
tantek: Leaving SHOULDs in there that four engines do not implement is a good way to block CR.
Rossen: Let's talk about this once we have more information
tantek: By downgrading we could go to CR faster.
Florian: Should I move the
at-risk section now? nav-left, nav-down, .... No one has worked
on them for years.
... Would rather push to next level
Rossen: Do it. Move it.
PROPOSED RESOLUTION: Move at-risk section to next level.
Florian: Google has had an intent
to implement which had problems. Concluded they wouldn't.
... Presto and old TVs do.
... Objection is "for tvs, why in browsers?"
... Would like to move to next level.
iank_: We rejected the intent for this.
tantek: I see light green passes for webkit here too.
Rossen: tantek, are you trying to keep this in spec?
tantek: Want evidence based decision
Rossen: Absolutely no browser implement. No interest.
tantek: Test results make it look more implemented then it is.
RESOLUTION: Move directional navigation properties, nav-up/down/left/right to next level
<fantasai> ScribeNick: fantasai
Rossen: Discussed 2018 summer
meeting
... meeting April in Berlin, coordnated with TypeO
... We speculatively were thinking of doing in Hawaii
(seriously, because easy for everyone to get to)
TabAtkins: Still on the table, but not finalized
astearns: I'm concerned about holding a meeting in the US
glazou: me too
astearns: bla bla on location
[discussion of options]
<dbaron> if you're looking for the closest non-US place to Hawaii, you want to look at how hard it is to travel to airport code NHV
<tantek> why not keep any survey inclusive of all options just to see how the US options rank relatively to others?
<eae> dbaron: Do you have an office in NHV? :)
<tantek> what are all the options for the summer meeting?
<dbaron> eae, no
<eae> Sad panda
current ideas include Toronto and various other Google offices in Canada, Sydney, Taipei
dino: costs of travel to Sydney?
various: a lot
TabAtkins: that's why we were seriously considering Hawaii, would actually cost us less than Sydney
<eae> Agree with tantek, why don't we vote on all options?
<glazou> Iceland ?
<glazou> Stockholm in july is gorgeous btw
tantek: why not vote on locations?
astearns: My concern with US is minority that doesn't want to come / can't come
TabAtkins: consensus poll, not actual vote
astearns: that might work
Rossen: ok, let's break for lunch
<br type=lunch>
<tantek> yes, consensus poll please among all options, with anon option
<dbaron> eae, it would be even cooler if we had an office in MOZ
<astearns> we'll start again in 5 mins
<gsnedders> RRSAgent: draft minutes
<gsnedders> RRSAgent: make minutes public
<gsnedders> RRSAgent: make logs public]
<gsnedders> RRSAgent: make logs public
<astearns> *your
<fremy> ScribeNick: fremy
<myles_> https://github.com/w3c/csswg-drafts/issues/1641
<myles_> https://github.com/w3c/csswg-drafts/issues/1133
<astearns> github: https://github.com/w3c/csswg-drafts/issues/1133
Github: https://github.com/w3c/csswg-drafts/issues/1133
myles_: for a long time, at font
face without src is ignored
... which means it is a parse error and is not there
anymore
dbaron: i would argue ignored could mean it's there in the om but then does nothing
myles_: ok, I think it doesn't
matter for what I want to think about
... in some cases, you can have font faces to alter font
properties
... and all browsers accept to do that
... so I would like the text to be changed to say that the font
face rule should not be used for font matching
... but should apply otherwise
dbaron: i think that is the sensible way to "ignore" them
TabAtkins: I have a follow-up question about whether we should apply a similar reasoning to invalid counter styles
dbaron: it would make sense to me
myles_: I cannot say that this matches browsers in that case, i have not tested
TabAtkins: sounds good, but we could decide on a principle and update if needed
Alan: what is the proposition then?
myles_: (repeats previous proposal)
RESOLUTION: font face rules should be in the om, but should not be used for font matching
RESOLUTION: font face rules should be in the om, but should not be used for font matching (correction of previous statement)
github: https://github.com/w3c/csswg-drafts/issues/1641
myles_: font-synthesis is a
property that allows to turn on/off the font synthesis
... for example font-synthesis: weight allows to generate
bolder variants
... by default you can synthetize everything
... the issue is that if you want to turn one on, you turn off
all the other ones
... which means that new flags will be aciddentally turned off
by older styles
fantasai: we have a similar
problem with text-decoration-skip
... we decided to create sub longhands properties
Florian: we don't have quite resolved that but ok
fantasai: the other option is to only reset to false what you specify as off, but if you don't specify things we use the default
Florian: wait, don't you want the reverse?
fantasai: if you omit them, they default to true if true is the default, yes
<Rossen> !add
fantasai: there was a proposal from ChrisL that was similar but used + and - in front of keywords
TabAtkins: text-decoration only allows to append new decoration styles but not remove inherited ones
Florian: the reason we rejected
the equivalent bold/no-bold for text-decoration because it
cascades poorly which is the case for text decoration
... this is not quite the case for font-synthesis though so the
option is still open now
fantasai: given that we already
follow that pattern for font-variant, I think we should use the
bold|no-bold pattern as well
... ... for font-synthesis
myles_: this is my opinion as
well
... plus some rule that explains what happens if you ask
both
Florian: should we also also have no-everything?
myles_: we can discuss this as part of another issue
alan: is this ok to make this change?
myles_: we added font-caps and
didn't see a problem
... but the window is closing of course, the more we add the
more difficult it gets to change
alan: so, proposed resolution is
to use pair-keywords values for this property
... any objection?
RESOLUTION: change font-synthesis to all pairs of keywords and no-keywords
fantasai: do we need to change fonts level 3?
myles_: don't think so
<myles_> https://github.com/w3ctag/design-reviews/issues/183
<TabAtkins> GitHub: https://github.com/w3ctag/design-reviews/issues/183
github: https://github.com/w3ctag/design-reviews/issues/183
dbaron: drott asked for tag
review
... the main feedback was how this should be font properties or
descriptors
... the reasoning should be that some things should be whether
you would want the things to apply to fallback fonts or
not
... over time, system fonts are likely to get more
variations
<TabAtkins> Looks like the axixes would be best done as an open-ended set of properties, similar to custom properties...
myles_: there are two spaces
<TabAtkins> We can't guarantee that the axis names live in the CSS ident space, so we can't do `font-axis-*` tho.
myles_: one is for things that
are defined for all fonts
... and things that are custom for your own font, which are
used in all caps
TabAtkins: what is the ascii range for these names?
myles_: less than ascii for
sure
... no control char or anything, and casing does matter
dbaron: flip side is
animation
... if you want to animate them, they should be properties
eae: there have been clear request to support that
dbaron: I think it would make sense then to have both to support both use cases
myles_: this is what font-feature-settings is, minus some stories I rather not start talking about
<dbaron> github: https://github.com/w3c/csswg-drafts/issues/1652
TabAtkins: how about having a
list of values in the axis?
... we still need to be able to control them
independantly
... we can instead allocate a property namespace so that you
get a property for each axis
fantasai: what if axis idents are outside ascii range in newer formats
TabAtkins: you can escape any char in identifiers in css
myles_: in our impl we would not want weird axis names anyway
alan: use case where you have weight animated
myles_: you can animate pair by pair
TabAtkins: but you still need to change all of them in same declaration
myles_: additive css would solve that
TabAtkins: yes
myles_: so, based on consensus we need a resolution to add descriptor and keep property
fantasai: we have a similar
problem with various stylistic fonts tags you want to turn on
and off
... what we did, we decided to tie them to an identifer that is
font-specific
... we could take the same approach here
... this would allow to customize a font-specific thing in
particular without affecting other fonts
That works for stylistic alternates because the meaning of "alternate #1" is arbitrary but it doesn't make sense for axis names because the meaning of a value is supposed to be consistent across fonts
TabAtkins: also the ranges could not mean the same thing for each font even if the two axises do approximately the same thing
<myles_> That works for stylistic alternates because the meaning of "alternate #1" is arbitrary but it doesn't make sense for axis names because the meaning of a value is supposed to be consistent across fonts
alan: even the lower-case standardized names, do they have identical ranges?
myles_: no
... names are consistent between formats, but ranges are
not
... they are internally consistent per format though
alan: could we map one to the other?
myles_: yes, we could map to a canonical form
alan: so could we define a css range?
myles_: I don't want to get into that
alan: anyway, I didn't hear any
opposition to have things be both font descriptors and
properties as per tag review
... can we get this resolved?
RESOLUTION: font variations will be both properties and descriptors
alan: any other issue we should discuss from this review?
dbaron: not really, the rest is mostly editorial
<Zakim> Bert, you wanted to ask (about previous topic) what 'font-synth: no-weight style' means for small-caps: Is small-caps synthesis on (beacuse it is not explicitly turned off) or off
Bert: so font-synthesis: no-abc --> turns off abc but on def, right?
myles_: well, it resets def to
its default
... right now all the other values are on by default, but in
the future we could add new things that would be off by
default
Bert: then why should we not change the fonts spec
myles_: no, it would just do as today, the spec will still be internally consistent
fantasai: well, new features will be off by default all the time right? otherwise it will be breaking change
Florian: not really, because new
features could be things that did not exist at all before
... so there would be no possible backwards compat problem
fantasai: and small-caps?
myles_: it is not in level 3, so no revision to do
fantasai: but with this we could
backport to level 3
... wouldn't you want that then?
myles_: to prevent a browser that support "small-caps" but "not-smallcaps"?
fantasai: yes
<fantasai> fantasai: We could have small-caps be on in the initial value and also be on if omitted
dbaron: well, i think there is still a change from level 3
<fantasai> fantasai: The ability to do this is effectively why we are considering having this foo/no-foo syntax.
TabAtkins: this is not the same
default we are talking about
... now we talk about "default if you omit it in the
declaration" not the "default if you omit the declaration"
dbaron: is this widely implemented?
myles_: no
dbaron and tabatkins arguing about default vs initial
dbaron: i would want the default if omitted to be the same as the initial
fantasai: +1
<TabAtkins> [dbaron kept using "default" to mean "initial value", when I and Myles were purposely using "default" to mean a totally separate concept]
fantasai: if we don't do what david wants, yes, there is not breaking change
fantasai: but if we accept to break stuff, we can do default=initial, which makes more sense
<dbaron> github: https://github.com/w3c/csswg-drafts/issues/1641
alan: seems like we want a new
issue, and try to come up with a new design for this, and
discuss this in a smaller group
... then come back to this when the key people for this issue
agree all together
fantasai: it is a breaking change, so we want to do it sooner rather than later
alan: what is the proposal then?
dbaron: intial = default
TabAtkins: "font-synthesis:
weight" also turns on "italic"
... that is confusing
myles_: we could three set of keywords
<TabAtkins> none | [ weight || style ] | [ [weight-on | weight-off] || [style-on | style-off] || [smallcaps-on | smallcaps-off] ... ]
Florian: or we can also use the
inheritance behavior
... the only case that would be broken would be
font-synthesis:initial
myles_: probably not common
dbaron: with this in mind, maybe
i am fine with the previous resolution
... if we need to do something weird anyway, we might as well
do what we proposed before
... but keep this as exceptions only for weight and style, and
going forward we do default=initial
alan: so we have three proposals
1. previous resolution
2. extended keyword set
3. inheritance for omitted values
fantasai: 3 would break the meaning for font-synthesis:weight
TabAtkins: no, it would not
Florian: we change the initial to
no
... but the ua stylesheet sets to true on root
alan: what about small-caps?
myles_: small caps is on by default
<Bert> (Idea: Disallow mixing positive and negative keywords. E.g., assume initial value is 'a b d' and you set 'a c', then only a and c are on. If you set 'no-a no-c' then b and are on, i.e., the initial value minus the ones that were turned off.)
myles_: so font-synthesis:weight allows small-caps
alan: do you have a preference, myles?
myles_: not really
... the ua stylesheet case is the most simple and elegant
solution, probably
TabAtkins: I like florian proposal
dino: the only issue is we break all:initial, which people do in shadow dom
TabAtkins: yes, true
fantasai: if we were doing this from scratch, we would have dbaron's behavior
<TabAtkins> Florian's proposal: initial value is `font-synthesis: no-weight no-style smallcaps`, UA style is `:root { font-syntheses: weight style smallcaps;}`. Omitting a keyword defaults it to the initial value for that keyword.
fantasai: how about we break existing content?
<TabAtkins> So author saying `f-s: weight;` would get weight & smallcaps syntheses, but not style.
myles_: places that use it today
would then never synthetize small caps
... i prefer the alternative
<fantasai> fremy: Why would you do 'all: initial' and not 'all: unset'?
alan: we reached the time
limit
... i would want to come to a conclusion
dbaron: two proposals: fixing previous resolution, or breaking existing content
<Bert> (idea2: use Chris's +/-. If you use a + or -, then the rule becomes "additive" :-) (relative to the initial value. 'font-synth: +weight' does not turn style off.)
<dbaron> Proposed resolution: make default values: weight (off), style (off), small-caps (on), make the initial value 'weight style', and add keywords no-weight, no-style, and no-small-caps.
<dbaron> More breaking option: make default values: weight (on), style (on), and small-caps (on), make the initial value 'new keyword to be determined', and add keywords no-weight, no-style, and no-small-caps
<dbaron> (although there's actually the alternative option to not have the non-default no-* variants)
<dbaron> (that alternative applies to both options)
alan: we try to resolve on the the first one dbaron proposed
(no objection)
RESOLUTION: make default values: weight (off), style (off), small-caps (on), make the initial value 'weight style', and add keywords no-weight, no-style, and no-small-caps.
<dbaron> (at least for now, may discuss further)
<myles_> https://github.com/w3c/csswg-drafts/issues/825
<astearns> github: https://github.com/w3c/csswg-drafts/issues/825
myles_: cssom for the font-face
rule
... used to be CSSStyleDeclaration with the declarations
inside
... rule.style.getPropertyValue("font-family")
... the spec was then changed
... instead of having a style, you would have a bunch of
strings
... e.g. rule.family
... no browser has made this change
... there is existing code that use the old way
... we don't want to break that code
... option 1: rollback to old spec text
... option 2: get browsers to support the new spec text
... option 3: get browsers to support both
... option 4: make the "style" property return new type of
object that looks like CSSStyleDeclaration but is simpler
dbaron: in the old domstyle spec,
cssstyledeclaration was simple
... the weird stuff was in css2properties, which had a property
for every property in css
... so you could implement both, and most things did
... that was then changed, and the two were merged
... so now the merge made it more difficult to implement
... we never implemented this merge
... (in gecko)
... my preferred proposal would then to be unmerge things
<fantasai> dbaron: our implementation doesn't include all the other stuff in font face rules, just the 6 original get/set methods
<fantasai> (that goes up a few lines)
dbaron: (and rollback to use cssstyledeclaration)
myles_: we still need to explain
what happens when we set properties that do not exist in
@font-face but do in general style
... but I don't have a strong opinion in either ways
... but I would rather rollback the spec, and maybe we can
refine after
alan: so, instead of coming up with a perfect design, we rollback the improve iteratively
TabAtkins: we have copied the
design in font-face
... and we have "style" property there
... so we cannot be consistent and keep style as
CSSStyleDeclaration
myles_: life is terrible, who names these things ;)
dbaron: if other implementations are willing to remove css2props stuff, then it leaves less questions to be answered
myles_: i dont think we ever implemented these two interfaces
alan: any other opinion?
TabAtkins: i suspect if gecko is doing it, i guess we could do it
myles_: merge allows rule.style.fontFamily and unmerge does not
dbaron: yes
myles_: webkit does not support this either
<gsnedders> I thought both of those were supported interoperably?
myles_: can we then try to resolve on rolling back to the unmerged version?
no objection
<dbaron> gsnedders: rule is CSSFontFaceRule
RESOLUTION: rollback to previous state with CSSStyleDeclaration and umerged interfaces
<myles_> https://github.com/w3c/csswg-drafts/issues/1349
<myles_> https://github.com/w3c/csswg-drafts/issues/1636#issuecomment-317127312
myles_: I made an amazing table,
let me paste the link
... there seems to be consensus that the font shorthand resets
what is not specified in it
... but what the other things are doesn't seem
interoperable
dbaron: I think the test is wrong for font-language-override
myles_: let me check
TabAtkins: there seems to be
things we do support that this test says we dont
... so we cannot trust this data
<TabAtkins> font-size-adjust, at minimum - we def support it (it causes the CSSWG blog to display brokenly on a Chromebook >_<)
myles_: ok, we will discuss this another day then
<myles_> https://github.com/w3c/csswg-drafts/issues/1579
<astearns> github: https://github.com/w3c/csswg-drafts/issues/1579
myles_: two things here
... 1. requested font weight
... 2. available options in the font
... then algorithm match one to the others
... for historical reasons, if you want 400 and it is not
possible
... search will be 300, then 500, then 200, then ...
... variables fonts can have much more arbitrary values
<fantasai> 500, then 300, then 200 I think
myles_: so I tried to come up
with a solution for generalizing this
... (connecting laptop to tv screens)
... the generalization i came up with: 400, then 500, then any
value between 400 and 300, then any value between 400 and 600,
etc
fantasai: why not directly 400
-> 500 instead of 400 then discretely 500
... doesn't seem very logical
TabAtkins: the old model did that
fantasai: but you could not
express 430, it needed to be hundred multiples
... the goal of the algorithm was that 400 and 500 were very
common values
... but 300 is often lightweight
... this proposal preserves the compat, but not the
spirit
... I would prefer to connect the 400 -> 500 range
TabAtkins: yes, it is less weird
myles: if there is concensus, i am ok with this
fantasai: this would evolve the
old algorithm, not run some algorithm after it
... proposal means if we did 400 then 500 then 300, now we do
400 -> 500, then 500 -> 300, ...
... obviously some values will not match
<fantasai> basically play "connect the dots" with the old search points
fantasai: because they have been searched already
<fantasai> which might go over some ranges multiple times, but of course the UA would optimize those out
(whiteboard discussion)
(the discussion seems to be about what fantasai's idea does if you search for 450 not 400)
(and related cases like 250 or 550)
<Rossen> [fantasai and myles are having hell of a time connecting dots and lines on the white board]
<TabAtkins> Split the weights into three categories:
<TabAtkins> light - < 400
<TabAtkins> medium - 400 <= x <= 500
<TabAtkins> bold - > 500
<TabAtkins> For light, first search from x => 0, then x => 1000
<TabAtkins> For bold, first search from x => 1000, then x => 0
<TabAtkins> For medium, several possiblities.
<TabAtkins> Never mind, bolder is better, so medium's category is: search x=>500, then x => 0, then x => 1000
RESOLUTION: font-weight matching described before
<TabAtkins> ScribeNick: TabAtkins
myles: Previously you could
animate font-weights, even tho they weren't numbers.
... You animated a number, then rounded to nearest 100, *then*
invoked the font selection algo.
... So at a particular value of time, say your animation was at
font-weight:540. You'd first round to 500, then run
font-selection.
... For variable fonts, you don't have to round. This is a good
thing.
... But rounding might change which case you fall into.
fantasai: And when animating between 401 and 450, rounding would make you choose the 400 font, but our new thing would choose the 500 font.
myles: So two options: undo what
we just did and make it more complicated...
... Or say that animating font-weights before variable fonts
wasn't often used, and just accept the behavior change.
fantasai: I think there's not
much objection to computing font-weight and its animation to be
a general integer.
... But for impls that don't do variable fonts, do we want them
to accept any value, or should they still do the rounding?
dbaron: There are fonts with more than just 100, 200, etc weights; seems like it would be better to make that work.
dauwhe: I have a font with weights spaced every 5.
dbaron: So I think we should just make the change; we'll see if there's any problem.
myles: I think we alreayd have an old resolution to let weight accept any integer, actually.
dbaron: Does the spec really mean <number> rather than <integer>?
myles: <number> is right; variables axises can accept any float in the range.
fantasai: So Fonts 3 needs to be updated; do we want to allow it at parse time too?
dbaron: I dont' think Fonts 3 needs updating; this is a new feature, the property just supports more values than it used to.
fantasai: That's fair.
TabAtkins: We could probably use a note in Fonts 4 that the animation behavior has changed.
myles: Yes.
astearns: Objections?
RESOLUTION: Font selection algorithm has different behavior during animation than Fonts 3; we will add a note to that affect in Fonts 4.
<nainar> scribenick: nainar
TabAtkins: first three issues are
deeply inter connected
... second one is keystone issue here.
<astearns> github: https://github.com/w3c/csswg-drafts/issues/1496
<astearns> github: https://github.com/w3c/csswg-drafts/issues/1496
<Florian> 1550 is not listed in the wiki, but also interconnected
<astearns> <whiteboarding again>
<fantasai> Tab draws a table with columns flow/flow-root, rows block/inline, and values block / BFC / inline-block / inline (clockwise)
<fantasai> Tab: block has to inlinify to inline-block, and inline-block has to blockify to block
https://www.irccloud.com/pastebin/8vyC7bj7/
TabAtkins: to make this happen
properly - we check if the value is a special value
... we could break the congruence between legacy values and the
two-keyword values so that we define that inline blockifies to
block and inline
<fantasai> ScribeNick: fantasai
TabAtkins: which would mean that
inline-block won't behave the same as inline flow-root
... even though they're the same thing
... I have an alternate suggestion
... It's still a little confusing, but maybe better
... That would avoid breaking existing implementations of
flow-root, which have already shipped
... First suggestion is that we stick with block and
inline
... But rather than just two values of flow/flow-root, we have
three, calling 1 2 and 3 atm
... in increasing order of BFCness
... Legacy inline is inline+1
... legacy block is block+2
... inline-block is inline+2
... 2 is the "keep my children together" value
... 3 is the even stronger one, so flow-root is block+3
<nainar> fantasai:
TabAtkins: and inline+3 is inline-super-block
Florian: What is an
inline-super-block?
... In which cases do they behave differently?
<nainar> fantasai: when does that matter?
TabAtkins: If it blockifies it blockifies to flow-root
(swap last two)
TabAtkins: You contain floats and
stuff
... So if you have a plain inline block
Rossen: You ahve two inline
blocks, and they are inside a flex. They both get
blockified
... If those have floats inside, those floats don't affect each
other
Florian, fantasai: Flex items are BFCs
Florian, fantasai: When does CSS blockify something and not turn it into a BFC also?
TabAtkins: I can't think of any case...
Florian: What about the block+1 case?
TabAtkins: tiny-block
... tiny-block inlinifies to inline
Florian: concrete example?
TabAtkins: If you have a normal
block inside of a ruby container. If you put a tiny-block into
a ruby then it turns into a regular inline
... falls out of the 2x3 array
... I guess then we have two values that fall out and aren't
really useful
... So in that case, I think we should have a diamond
Florian: So how's that different from 2x2?
TabAtkins: block and inline-block
correspond
... I guess flow-root oesn't inlinfiie? Or maybe becomes
inline-block?
TabAtkins draws a bunch of arrows
Florian: I don't know if this is useful.....
iank_: Why can't we ?
TabAtkins: Because block has to inlinifie to inline-block, and inline-block blockify to block.
fremy: getComputedStyle, right
Florian: that and display:
inherit, which nobody does
... Could we say that everything that BFCizes makes you go from
block to flow-root ans independnetly from ...
... Maybe?
TabAtkins: So given that block+1 doesn't have a use case, and neither does inline+3 ...
<nainar> fantasai: i think its silly to have a bunch of combos that is not useful - cant see how this is better
TabAtkins: I want inlinification
and blockification to be simple
... 2x2 grid doesn't work, have ot special case things
<nainar> fantasai: I think you're overemphasizing th imp of inlinification of swapping a keyword in an onut
<nainar> fantasai: if we take arrows this set of 4 values correspond like that it will be better.
<nainar> fantasai: we either have to syntatically disallow or have them do nothing
TabAtkins: ....
TabAtkins redraws original 2x2 grid
TabAtkins draws arrows representing inlinification and blockification
TabAtkins: You don't have pairs,
a flow-root inlinifies to an inline-block which then blockifies
to a block
... But that doesn't seem to be a practical concern
Florian: ...
gregwhitworth: Can you please use words?
Florian: If the only dif between
block and flow-root is being a BFC
... becoming a block ...?
<Rossen> [Florian frantically pointing at the whiteboard yelling "this"]
TabAtkins: Inline block currently
becomes a block when it blockifies
... It just happens to be an BFC in all these cases, but its
computed value is 'block'
... e.g. for flex items, if you specify 'display: inline-block'
and ask for its computed display you get 'block'
... Generally the case, also for abspos etc.
... Because 'flow-root' didn't exist 15 years ago
... I don't like it, but I'd be okay with just doing this
(points at 2x2)
... So it's fine.
... OK, so we can analyze the other things
... So if we have blockification /inlinification algos just
explicitly map these values in the 2x2 grid
... Then the next issue is ...
... This solves 1246
... where bz points out we get the wrong computed style (get
flow-root where breaks legacy)
(note to Dael, Rossen's comment goes into the Florian: ... line)
Florian: I believe the board is a re-resolution of 1246
TabAtkins: also resolves
1496
... Suggested resolution is that blockfiication of an inline
flow-root aka inline-block is defined to go to 'block'
... And inlinification of block flow special cases to inline
flow-root aka inline-block
<nainar> fantasai: 1486 is still open?
astearns: So sticking with 1496
RESOLUTION: Leave 'display' syntax as-is for #1496
RESOLUTION: For 1246, inlinification of 'block flow' goes to inline flow-root aka inline-block, blockfication of inline flow-root & inline-block go to 'block'
RESOLUTION: For 1486, issue is moot because 1246 resolution was reverted (above)
<nainar> fantasai: inline flow-root what is the computed value if we arent blockifying?
<nainar> fantasai: the serialization?
RESOLUTION: 'inline flow-root' serializes in getComputedStyle as 'inline-block'
Florian: https://github.com/w3c/csswg-drafts/issues/1550
TabAtkins: This is oriol asking, mechanisms that turn BFCs, why not make them all resolve to display: flow-root instead. And we can't due to web-compat
Florian: It's not that there are 2 behavior for flow, there are 4, and flow is way overloaded
TabAtkins: 2nd and 3rd are the same thing
(of some list that I missed, sorry)
TabAtkins: flow creates regular
blocks and sometiems BFC
... That's just the way it is
... oh, I see
... Actual suggestion is to change the value at used value
time
... That doesn't mean anything, because it's post box tree
construction
... Used values are for turning box tree into fragment tree
dbaron: no, used values are just
how we describe transformations that happen after
inheritance
... i.e. anything that's post-computation
<nainar> fantasai: is this editorial? he si saying tha tinstead of describing things as we have it - we shoudl vocab and change flow to flow-root for used value
"This change should have no effect in practice."
TabAtkins: ...
... computed value is eveyrthing before you inherit, and used
value is everything after inheritance
Florian: No way to distinguish,
but you could say that box tree is computed off of used value
of 'display'
... introducing this concept as a way of explaining what
happens
fremy: All the old specs we already have will be even more confusing
TabAtkins: We already have had to
edit every spec
... e.g. "height behaves as auto" thing
... Not actually every spec anywya
... Seems okay
... dbaron?
astearns: Given item wasn't on agenda, and this is first time apparently anyone understood it...
TabAtkins: OK, can discuss later
Florian: It was sort of on the agenda, next issue links to this one
astearns: OK, let's switch the topic and get minutes posted to the correct issues.
<astearns> github: https://github.com/w3c/csswg-drafts/issues/1457
TabAtkins: big issue is 'contain'
property
... which requires element to establish a formatting
context
... But it's not meaningful, can't just say it establish a
formatting context out of the blue, e.g. an 'inline' can
... can't establish a formatting context
... could say that it turns into an inline-block, tho
... But can't do that to Ruby
... So what should we do here?
... Most cases it's a no-op, grid/table/etc is a no-op
... block has an easy answer: switch to flow-root
... inline has an easy answer: switch to inline-block
... ruby is the only one that has a difficult issue
Florian: In other cases, we
haven't had a problem with this
... e.g. 'overflow' doesn't apply to inline/ruby, so don't have
to worry about these cases
... similarly column-span only applies to block-level elements,
so no problem there
... The only case where we have a problem is 'contain'
... which needed to apply to 'inline' and 'ruby'
... So we need to establish terminology, and oriol's suggestion
works for this
<nainar> fantasai: ruby can block
<nainar> fantasai: ruby spec defines block ruby. AYOu cant turn into a inline block ruby which is what you were trying to say
Florian: The alternative is to not add terminology for this, and just say that these things blockify and th
(shift that up)
Florian: Might be worth leaving
existing places the way they are
... and have 'contain' blockify, and the rest is obvious
... If there's an easy way to define this, then we should, and
then call into it ffrom all these places
... Oriol's suggestion solves this case
TabAtkins: So what should we do for ruby
<nainar> fantasai: two solutions here. third one is what you were trying to do - ruby makes an inline block ruby thing. No use case - not a good idea
<nainar> fantasai: second thing we could do - florian mentioned to blocify ruby and the inline. That is inconsitent with inline block. They get to stay as inline-blocks
<nainar> fantasai: weird to have ruby turn into a block element
<nainar> fantasai: you could turn all inline level things into block level things
<nainar> fantasai: last thing, this aspect of contain doesnt apply to inline/ruby - the author should change it into a block first. Author then chooses to make the display transformation
TabAtkins: No reason not to apply
contain to inline-block
... you mentioned block ruby
<nainar> fantasai: confirms that if you specify display block ruby you get a block with ruby inside it
fremy: ruby does special alignment things
Florian, fantasai: it's not different from iline
inline
TabAtkins: Can we make block ruby
a BFC?
... Only thing is that if you have a float, it won't intrude
the way it does for regular blocks
Rossen: No reason to have inline layout of ruby be different from regular inline layout
<nainar> fantasai: why not go with the last option?
TabAtkins: ...
<nainar> fantasai: to apply to neither inline/ruby - you the author must turn it into an inline-block or block (depending on the author's preference)
TabAtkins: Ok, I'm down with that
dbaron: Issue is that contain is that authors won't know what effects to get
TabAtkins: Then it's a no-op, they're putting it there for trash reasons
fremy: They're not getting worse
performance
...
dbaron: Elements nested inside each other, and accidentally stuck property on inline instead of the inline-block
fremy: dom inspector can show that it doesn't apply
astearns: What if they applied it to a box that was block, and then changed it to an inline and now they lose the perf benefits
<nainar> fantasai: keep in mind that if you had a contain on there - when you turned it into an inline you would not get the layout you expected.
<nainar> fantasai: if we didnt ignore it we would be forcing it into an inline then
fremy: Your question is like someone getting perf benefit from ? and then turning it off and wondering why benefit is gone...
astearns: I like the fact that 'contain' doesn't have the blockification transformation
TabAtkins: That would be a significant layout change, whereas for other things its relatively minor
Florian: After understandign it,
you used oriol's terminology, so regardless of whether we
become an FC, i would support adopting oriol's
terminology
... It seems to me that we are getting closer to fantasai's
position, which is to not define the idea of becoming an FC,
and for all the situations except contain that may have been
ambiguous it was good enough
... and for contain we will eliminate the problematic
situations so that it is also good enough
TabAtkins: First resolution is
for 1457, which is "what does it mean to become a formatting
context"
... resolution is that blocks become flow roots, inlines and
rubies can't establish a formatting context, and so any
property that tries ot nvoke this must exclude them
somehow
... so we will change 'contain' accordingly
astearns: dbaron?
dbaron: I think ppl often have a bunch of nested elements and the display types are pretty random, and that usually just work
TabAtkins: Kinda, until people
are like "why is there a 2px gap below this thing?" and it's
because they have an inline-block instead of a block
... You have to learn that
Florian: Or fix it with margin-bottom: -2px :D
T_T
dbaron: If they have a baseline,
won't have that problem tho
... only if they fail to have a baseline
astearns: So we could resolve on what Tab said, or resolve part of it
<Loirooriol> Hi CSSWG, what about 'block ruby'? The block container could establish a BFC.
astearns actually just asked that question to dbaron, didn't get a chance to type it yet :)
2nd question was also asked earlier, no answer yet
dbaron: I'm okay with resolving
but kinda concerned about making 'contain' even more
random
... I think one thing that is hard about web dev is that it's
hard to understand perf effects of things
... Part of why contain is useful is it provides a way to make
them more predictable
... by forcing various types of isolation
<TabAtkins> Loirooriol, It would be rather unfortunate if it was impossible to have block-ruby flow around a float; there's no reason to restrict that.
dbaron: If you make contain less reliable, then you're back to unreliable
fremy: I have a solution but no
one will like it
... display: none
... then author will find out it's a problem
fantasai: we don't do dataloss by default
Florian: Do we also need to stop confusing formatting contexts and formatting contexts?
TabAtkins: not directly relevant
<Loirooriol> Tabatkins, I meant only when 'contain' needs a formatting context
<TabAtkins> Loirooriol, then there's no way to create a block-ruby FC without using/ ? :) side-effects. :(
TabAtkins: Thinking to leave
'contain' issue undef for now
... or figure out something for ruby
... or say that contain doesn't apply to inline and ruby
... which do you like best?
dbaron: I guess I don't feel that
strongly
... I think you could say they become inline flow root or
...
<nainar> fantasai: I think we imply ... the container
<nainar> fantasai: I think if you turn display:ruby into flow-root you will.. Ruby does the same thing as table.
<nainar> fantasai: set display:flow-root on a ruby element you will get a block ruby BFC - all boxes in ruby will generate correctly.
<nainar> TabAtkins: you get a contained block and all the perf benefits there
<nainar> fantasai: you have sideeffects like we turn off inlinification
<nainar> fantasai: you have block boxes inside a ruby container they inlineify. They wont anymore
<nainar> fantasai: there will be some differences in behaviour.
<nainar> fantasai: it woudl break the case of not using rb elements to wrap bases?
<nainar> fantasai: because parent is no longer ruby container
<nainar> fantasai: scooping algo would not scoop up ruby bases that aren't in explicit elements
TabAtkins: Then let's go ahead and do Loirooriol's thing of having "used value of flow-root" terminology for all of our BFCs
astearns: Any resolution for becoming a formatting context?
TabAtkins: not yet
astearns: proposed resolution to take Oriol's proposal in 1550
TabAtkins: This is just an editorial change
RESOLUTION: Accept 1550
fantasai: Could say that the "becoming a formatting context" section is css-contain's problem, remove it from css-display
TabAtkins: yeah, since it's no
longer affecting anythng other than contain
... so let's move to 'contain' spec, mark ruby and stuff as
open issues
RESOLUTION: Move "becoming a formatting context" section back to css-contain, mark ruby/inline as open issues to figure out
TabAtkins: Bunch of untriaged issues from Oriol, will talk about them later
<TabAtkins> ScribeNick: TabAtkins
<astearns> github: https://github.com/w3c/csswg-drafts/issues/1250
Florian: There's an appearance
proeprty. We started standardizing it, because a lot of people
use "none" on form controls to make them styleable in
CSS.
... This previous existed as a prefixed form in most
browsers.
... Before stadndardization, the values other than none was a
very long list of all the ways an element could look; this list
was different across browsers.
... We concluded this was impossible to standardize, in part
because many apply to pseudo-elements that other browsers don't
have, as they construct form elements differently.
... Instead, we'd just have an "auto" value that makes form
controls look like whatever they need, and a "none" value that
suppresses it.
... We could possibly exxtend this into a small list of special
values, like "button" to make it look like a native button, but
so far ahve resolved not to.
... Now Moz said that they need to implement all of the
-webkit-appearance values.
... I'm a little suspicious.
dbaron: Not sure if that's
accurate.
... I think it's, *when* we implemented both appearance and
-webkit-appearance, sites broke.
Florian: They first said they
aliased them to each other, and that broke stuff.
... That's expected, they're very different.
... They said "we need to ipmlement all the -webkit values
anyway, so the simple one isn't useful to us"
dbaron: Not sure that's what we said/meant.
Florian: Then I'm confused and
need to know what they mean.
... "fwiw, we intend to support -webkit-appearance with all
values that Chrome supports" ~ Mats Palmgren, June 7
<astearns> comment here: https://github.com/w3c/csswg-drafts/issues/1250#issuecomment-306788821
dbaron: There are sites that specifically set "input { appearance: none; } input[type=checkbox] { appearance: checkbox; }"
Florian: We did say that, if
needed for webcompat, we could add a handful of required
values.
... This is very different from adding all 50+ webkit
values.
<tantek> FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=1368555
dbaron: If that's the case, then
don't put 'appearance' in a spec ready for impl.
... Otherwise people try to implement it.
<fantasai> TabAtkins: Maybe have a scary notice saying this is problemantic
<fantasai> Florian: I had that note. WG asked me to remove it.
<tantek> see the webcompat.com URLs in the above bugzilla bug
<fantasai> TabAtkins: I'm fine with putting note back
<fantasai> TabAtkins: to say that we might need some values
Florian: Cool. But that's different from saying we need all the webkit values. Because then we need all the webkit pseudo-elements, and I'm not speccing that.
jet: Doesn't mean we might not need it.
Florian: Maybe, but it'll be a huge effort. Need good proof it's needed.
<fantasai> and Florian should be given a correspondingly significant budget for working on it :)
TabAtkins: So suggestion: add note saying don't implement this property yet; it needs some subset of the -webkit-appearance values; impls need to tell us which subset is necessary
Florian: Initial draft included
the other values Edge supports for -webkit; presumably that's
for compat reasons.
... WG told me to remove it.
gregwhitworth: My recollection was a question whether it was even needed.
TabAtkins: David suggested we did - his example would break checkbox rendering.
dbaron: I don't know the exact details, there's so many bugs and compat stuff it'll take a while to untangle.
Florian: So two options: none | auto | <non-exhaustive-list> ; or none | <exhaustive-list>
fremy: Alternatiely: let it take any keyword, treat unknown ones as "auto".
Florian: That doesn't match today.
astearns: Why is "auto" only with non-exhaustive list?
<ericwilligers> +q
TabAtkins: We could put it with exhaustive, and we could omit it from the non-exhaustive list. Depends on details.
fremy: If you have "div { -webkit-appearance:button}", nothing happens. But "input { -webkit-appearance: none; }" does work; using "checkbox" will work on a checkbox input, but won't turn a text input into a checkbox.
ericwilligers: I heard dbaron say that if they ship appearance it'll break compat. Can we just change the name?
<fremy> TabAtkins, yes
Florian: And then we can avoid saying "none", and use "normal" instead, which sounds better.
<tantek> per https://github.com/w3c/csswg-drafts/issues/1250#issuecomment-306788821
dino: Who implements unprefixed appearance?
<fremy> TabAtkins, input { -webkit-apperance:none} input[type=button] { -webkit-appearance: checkbox } renders as a button
Florian: Nobody that I know, but I last checked a while ago.
dbaron: We tried, but backed it
out before it hit stable.
... It's not clear what portions of the problem were with
"appearance" and which were with "-webkit-appearance".
dino: I was considering implementing unprefixed with just "none" and "auto".
<Zakim> tantek, you wanted to note or we go with original guidance to drop appearance from CSS UI, and let it get documented in https://compat.spec.whatwg.org/ instead (all prefix or not
tantek: One of the points Mats
made is that this isn't a particularly useful feature for web
authors.
... So one proposal is just to drop it entirely.
fantasai: People use it a lot.
TabAtkins: I use "none" plenty to do styles on my buttons, etc.
dbaron: It's not cleaer to me
which of these was the good reason to back the whole thing
out.
... ONe of my guidelines is that if a user reports a bug,
that's a compat problem; if the dev does, that's not
necessarily a compat problem.
... And one of them was reported by a dev, because it comes
with a jsfiddle.
<fantasai> TabAtkins: That said, your example looks believable
<fantasai> TabAtkins: It would be fixed by fremy's proposal
<fantasai> astearns: would also be fixed by minting an entirely new property
astearns: So that seems like a cleaner solution.
TabAtkins: Possible conclusion, just leave this unresolved, but note the handful of possible solutions and ask impls to tell us which they want to do.
Florian: Seems better than trashing it.
<tantek> seems like a lot of work for very little benefit
<tantek> so I question why
RESOLUTION: Put a note into "appearance" saying it's not ready to implement, list the possible solutions discussed here, ask impls which they want to do.
<fantasai> TabAtkins: Answer to tantek's question is that people use it for useful things today
<fantasai> TabAtkins: and there is no other solution for what they want today
<tantek> where is the documentation of the use-case in the spec? let's drop a URL here for the minutes
Florian: Another warning for the
spec: the high-level doesn't need to change, but details are
insufficient.
... When you appearance:none something, the native-ness goes
away.
... AND this does not affect its beahvior; events still happen,
etc.
... This is established.
... Waht's not established is: if you "none" a button, does it
look loike an unstyled div, or is there UA styles that make it
button-y, which you can replace.
... Another thing: for a range input, you probably can remove
the graduation on the bar that tells you where you are, but you
can't remove the thumb; otherwise you have nothing to
drag.
... So going from the high-level principles that you need to
keep it interactive, we need to dive into every control and
specify what disappears, what is done by the UA stylesheet, and
what is kept no matter what.
... If you want me to spend time doing this, say so.
dbaron: I think some impls can assume they always have a native appearance.
<tantek> how high does the cost have to go before it is obviously not worth the supposed benefit?
dbaron: A number of platforms
provide an API that says "draw a background of a button".
... The original spec didn't say this, but I think both impls
of appearance were about replacing the border/background of a
button/widget with a native one.
... On some platforms you can rely on these native APIs always
being present and always working.
... On some you can't.
... Not sure if we care about those platforms, but we
might.
... One thing that led us to retain our UA stylesheet is
because they always existed as fallback, for when the platform
couldn't draw a native thing
... I think an example was older versions of windows not having
all the widgets, or Linux themes not always being
capable.
... At least GTK2, theme might be unable to draw if provided a
surface that wasn't a real GTK window, so you had to do
something else.
Florian: I think this is extra
background for what I tried to state earlier; a combination of
principle and compat requirements means that there must be
*something* in the UA stylesheet.
... This research hasn't happened.
dbaron: And specifying
border/background explicitly also turns off appearance, on most
(all?) things.
... And there are cases that "appearance:none" also turns off
*more* things.
... FF didn't do this, but WK eventually started doing this, so
there's lots of weird logic now.
dino: I don't think there's much
we turn off with "none".
... Some cases where you'd get a native widget, but styles
change it to a non-native widget, so it changes appearance
dramatically...
dbaron: Some examples: the drop
marker in a combo box...
... If you say appearance:none, the dropdown arrow next to a
<select> disappears; setting border/background doesn't do
this.
<fantasai> TabAtkins: Setting border/background doesn't kill the drop-down
<fantasai> TabAtkins: But setting 'appearance: none does'
Florian: And the spec is trying
to require that behavior, because right now it's unpredictable
what will show up.
... Because you don't know whether it'll be there or not, and
the pseudo-element varies per browser, when we style it with
CSS we need to specify what you actually get.
astearns: THis is all interesting, but I"m not sure we need to go further into the weeds right now.
Florian: Yes, I'm planning on putting in a warning for this.
<tantek> astearns++, weeds--
<dbaron> 0A%20%20%3Coption%3EOne%3C%2Foption%3E%0A%3C%2Fselect%3E
<astearns> github: https://github.com/w3c/csswg-drafts/issues/1636
myles: Thanks to David, we now
have a bunch of correct data.
... [presents it]
... I think there's some consensus that 'font' can reset
properties that it can't set.
TabAtkins: It has some "reset-only sub-properties".
myles: [explains table]
dbaron: Further question: what's a subproperty of font-variant?
myles: So should we look for that
data too?
... So does anyone outside of dbaron have opintions on
this?
TabAtkins: I think font-synthesis shouldn't be reset, everything else I don't care, probably be reset.
dbaron: My pref is for 'font' to reset the font you specified, and not leave a bunch of stuff unresolved.
fantasai: I strongly agree with Firefox's group, except unsure about font-kerning.
myles: optical-sizing should be reset.
<fantasai> ?^: What about the unsupported ones?
dbaron: I think it's important that variation-settings and feature-setting get reset.
[general agreement]
<fantasai> fantasai^: don't know what optical-sizing is, but agree with resetting all of those as well
astearns: Why not font-synthesis?
TabAtkins: It seems like it's rarely tied to the precise font; usually if you care, you'll amke sure all your fonts have it.
myles: Same probably applies to font-presentation.
[general agreement]
[general agreement that all the others should be; we went thru several specific examples]
Florian: I'm not sure about font-variant
myles: That's *set* by the 'font' shorthand, it *must* be reset.
RESOLUTION: All font-* properties are reset by the font shorthand, except font-presentation and font-synthesis.
github-bot, end topic
<fantasai> How about font-iconography?
tantek: Yesterday we talked about
langauge of counter-styles when read out; we had weak consensus
but no strong reasoning.
... Since then, tab explained to me his reasoning for it being
defined by the UA language.
<bdc> (agree with fantasai, it's super generic -- just like appearance btw)
tantek: So we should revisit.
dbaron: I really don't like
making things a function of the UA, as that makes a webpage
testing problem that most devs are totally aware of.
... EAsy to make things that work fine with an English browser,
and are strange with a Chinese browser.
... Encoding is an example.
<tantek> scribenick: fantasai
TabAtkins: I agree with dbaron in
general, but don't believ ehtis falls into that bucket of
problems
... This is about how to read numeric counter styles
... when you're in a screen reader UA need to read out in
numeric numbers
<TabAtkins> fantasai: I don't think that's what it's about.
<TabAtkins> fantasai: If you're reading a french webpage in an English UA, using alphabetic numbering, the UA will read it as "A B C" (english)
<TabAtkins> fantasai: Weird to suddenly swap; the rest of the text is referring to option A in French.
TabAtkins: Screen readers are relying on numbers to navigate the page, need to have it in their UI language
<TabAtkins> Florian: I think I can turn you argument on its head.
TabAtkins^: Mismatch of the text referring to "option ah" and list reading out as "list item ay" shouldn't matter because the reader understands both languages
<TabAtkins> Florian: If you're reading a webpage in French, it's unlikely that, if it's in French, it would be usable with the bullets in English.
<TabAtkins> Florian: So having a page of nonsense with a sensible list bullet in the middle of it is not useful.
<TabAtkins> fantasai: If you're running a screenreader UA, and you always want the numeric value of a list, it should have such an option to use numeric values regarldess of bullet style.
<TabAtkins> fantasai: It's a navigation interface at that point; different thing.
TabAtkins: Relying on page
language then is okay, but using element's language is not
good
... Mostly english English page with some spanish text,
switches numbering, not good
<TabAtkins> fantasai: So this isn't a question for a11y, but i18n. Maybe a bit of both.
<TabAtkins> fantasai: But mostly i18n people.
<TabAtkins> astearns: I have an opinion, but I don't think ti's worth as much as polling people who use screenreaders with multipole languages.
<TabAtkins> fremy: In an English comp, page is in French, even if your screenreader can read french, it'll read a button with French Text like "<french text> disabled" - speaking "disabled" in English.
<TabAtkins> fremy: So I'm used to switching; it would be weird if it said "disabled" in french.
<TabAtkins> TabAtkins: That matches with the "lang of the UA", not page or element.
fantasai: Here is the problem I
don't want us to have
... You have an ebook in French, and your reader is reading the
ebook
... It reads out "Chapitre twenty-three, François va à
Seattle"
... rather than "Chapitre vingt-trois, François va à
Seattle"
... because you used CSS counters and GC to generate the
chapter numbers
... Instead of inlining them into the document source
TabAtkins: That's a good
example
... It sems that goe back to your earlier example of navigation
being important to read in the UA language
... I'm okay with saying that counte rstyles are read out in
the element language
... but adding a note that when reading out numbers as a
navigation aid, that's part of the UA interface
<TabAtkins> astearns: And both of these things should be read by i18n and a11y.
<TabAtkins> fantasai: Right. We'll edit it together, I'll edit Text to have the right hook and make sure it's published, and then we'll ask for review once we have the prose.
<TabAtkins> astearns: This isn't a requirement for the browser, but for the screenreader.
I think it has the right hook at the moment, just hasn't been published in a really long time so we can'tlink to it from counter-styles :)
<TabAtkins> TabAtkins: Right, the browser isn't using it as a navigation aid.
<TabAtkins> Florian: Might want an exception for lists - don't want "famous authors: one, Steven King; ni, Murakami, ...". Should maybe take lang from the list isntead.
<TabAtkins> fantasai: That's bad markup - the list item itself is English in this context. If you're marking any Japanese, it should be in a span around the name only.
<TabAtkins> fantasai: So that just needs more accurdate markup; it's not for us to fix.
RESOLUTION: same resolution as yesterday :)
<TabAtkins> github-bot, end topic
<Bert> (I can imagine a clean-up tool that sees <foo><span attr=val>...</span></foo> and replaces it with <foo attr-val>...</foo>, because <span> doesn't have semantics other than its attributes, to here it is redundant...)
bdc, https://github.com/w3c/csswg-drafts/issues/1092
<bdc> tantek: now we're "done" with this, mind elaborating why you think `appearance` is useless?
<tantek> bdc, not "useless", but rather, cost far exceeds benefits
<bdc> so, let's just say for a moment it'd only support `none`
<bdc> (which is arguably the most common use case)
<bdc> would you still have the same opinion?
<tantek> bdc, yes that was the initial consensus at the NYC f2f like 3 years ago?
<tantek> and then scope creep to button to other values in theory
<tantek> and then it was pretty obvious with impl experience that all that was a bad idea
<tantek> so now there is a ton of time/work being put into trying to salvage it
<bdc> ok yeah I lack some context there, but anecdotally, I see appearance:none being used _everywhere_
<bdc> as in, we can't deny it's essential
<bdc> I've personally used it recently on the homepage of https://stripe.com
<bdc> for the dropdown menu
<bdc> I just want the native `select` behavior
<bdc> but a different presentation on mobile
<bdc> and no way I'm recreating an entire custom `select` just to customize the default appearance
<tantek> ok then we should re-resolve to *only* have appearance:none, define it accordingly (all the things it "turns of"), and resolve NOT to add any other values to appearance
<bdc> that'd work for me
<tantek> except the initial "UA automagic behavior" which I guess is what people intend by appearance:auto
<bdc> exactly yeah
<tantek> since there has to be an initial value
<bdc> yeah
<bdc> that'd be incomplete but still a lot better than nothing
<bdc> imho
<tantek> anything beyond that is so not worth all the time already spent, nevermind time to be spent
<bdc> totally agree
<tantek> bdc, heh "incomplete" is the enemy of useful :P
<bdc> well I don't have actual numbers, but I'd suspect the incompleteness of only supporting `none` would cover the vast majority of use cases
<bdc> so it'd still be pretty useful ¯\_(ツ)_/¯
<tantek> bdc, aside: 'appearance' and the evolution thereof, is my fault: https://www.w3.org/TR/2002/WD-css3-ui-20020802/#appearance
<tantek> good lesson in the need to incubate before taking something to a WD that eventually goes to CR
<bdc> hah
<tantek> and I was in the process of implementing it in Tasman and iterating the spec, when work on Tasman stopped, and I should have pulled it from the spec since no one else was (maybe Gecko had something in progress?)
<gsnedders> I thought the conclusion was always to just standardise what tantek implemented in Tasman rather than continuing to discuss it for another two decades before making a resolution?
<tantek> gsnedders: right, that was the problem, the implementation was incomplete and never proved out the feature
<tantek> and yet I was trying to iterate in public (this was long before public EDs)
<gsnedders> and a closed impl
<tantek> which is ok to demonstrate implementability / verify it works as intended for authoring use-cases
<gsnedders> i just mean insofar as it made it harder to put the draft spec in some impl space
<tantek> on the contrary - it's better to have 2nd .. etc. impl *not* be able to look at the internals of 1st impl. forces the details to be expressed in the spec.
<gsnedders> I'm never convinced that that makes it very different; I know few who do much code reading v. black-box reverse engineering
<tantek> or at least it forces expressing details as test cases instead of source code
<tantek> gsnedders, I was also a big fan of including simple test cases in the spec itself
<astearns> trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/min-width/min-width percentage only on these elements/ Succeeded: s/please/I guess I'm OK with this, but please/ Succeeded: s/extended/extended in css-tables-3/ Succeeded: s/bheave/behave/ Succeeded: s/dbaron: Web will probably end up with one layout engine by the time we get around to fixing this...// Succeeded: s/club/clip/ Succeeded: s/WOF/WOFF/ Succeeded: s/no body/nobody/ Succeeded: s/implemtor/implementor/ Succeeded: s/Any/glazou: Any/ Succeeded: s/group/group to commit resources for testing to this group, not just send people to work on specs and implementations/ Succeeded: s/of this group/of this group to dedicate participating engineers' time to write tests FOR THE WG, which they don't atm/ Succeeded: s/tests/tests, not at unreviewed PRs/ Succeeded: s/tests/tests, but it's better than none, yes/ Succeeded: s/waste/huge waste/ :p/ Succeeded: s/Comments/Comments or quotes from the spec/ Succeeded: s/Florian/fantasai/ Succeeded: s/list of changes/list of changes for CR updates/ Succeeded: s/in the PR to CR/in the CR to PR/ Succeeded: s/reuslts/results/ Succeeded: s/F2F scheduling/F2F scheduling https://wiki.csswg.org/planning/ Succeeded: s/Prefer somewhere not in the US/bla bla on location/ Succeeded: s/, apply for font settings// Succeeded: s/proposal/proposal from ChrisL/ Succeeded: s/want to/already/ Succeeded: s/other things like /font-/ Succeeded: s/do that/use the bold|no-bold pattern/ Succeeded: s/text/fonts/ Succeeded: s/???/drott/ Succeeded: s/the issue is that each axis might change of/what if axis idents are outside/ Succeeded: s/that/weird axis names/ Succeeded: s/name is identical/the two axises do approximately the same thing/ Succeeded: s/myles_: that would work for named axises but some are just number-indexed/That works for stylistic alternates because the meaning of "alternate #1" is arbitrary but it doesn't make sense for axis names because the meaning of a value is supposed to be consistent across fonts/ Succeeded: s/default/default if omitted/ Succeeded: s/css2properties/css2properties, which had a property for every property in css/ Succeeded: s/rule.style["font-family"]/rule.style.fontFamily/ Succeeded: s/this/generalizing this/ Succeeded: s/TopicL/Topic:/ Succeeded: s/andthe keywrod values/and the two-keyword values/ Succeeded: s/inline-1/inline+1/ Succeeded: s/combo/bunch of combos/ Succeeded: s/overex=hasizng/overemphasizing/ Succeeded: s/cant/can/ Succeeded: s/preferred/depending on the author's preference/ Succeeded: s/solution/solution but no one will like it/ Succeeded: s/without/without using/ ? :)/ Succeeded: s/inline ruby/inline and ruby/ Succeeded: s/of/off/ Succeeded: s/.../not scoop up ruby bases that aren't in explicit elements/ Succeeded: s/RESOLVE/RESOLVED/ Succeeded: s/not/not necessarily/ Succeeded: s/neative/native/ Succeeded: s/astearn/astearns/ Succeeded: s/maybe font-kerning not being reset/unsure about font-kerning/ Succeeded: s/agree/strongly agree/ Succeeded: s/screen reader UA/screen reader UA need to read out in numeric numbers/ Succeeded: s/option A/option A in French/ Succeeded: s/option/option to use numeric values regarldess of bullet style/ Succeeded: s/hook/hook and make sure it's published/ Default Present: tantek, dael, Rossen_, antenna, dauwhe, jensimmons, tgraham`, TomoyaKimura, rachelandrew, antonp, Bert, alex_antennahouse, tmichel, AmeliaBR, gregwhitworth, Rossen, astearns, iank_, glazou, :, Myles_, Florian, eae, dbaron, flackr, jet, Surma, svillar, fantasai, plinss, melanierichards, gsnedders, bdc, nainar Present: tantek dael Rossen_ antenna dauwhe jensimmons tgraham` TomoyaKimura rachelandrew antonp Bert alex_antennahouse tmichel AmeliaBR gregwhitworth Rossen astearns iank_ glazou : Myles_ Florian eae dbaron flackr jet Surma svillar fantasai plinss melanierichards gsnedders bdc nainar Myles Found ScribeNick: fantasai Found ScribeNick: eae Found ScribeNick: fantasai Found ScribeNick: fremy Found ScribeNick: TabAtkins Found ScribeNick: nainar Found ScribeNick: fantasai Found ScribeNick: TabAtkins Found ScribeNick: fantasai Inferring Scribes: fantasai, eae, fremy, TabAtkins, nainar Scribes: fantasai, eae, fremy, TabAtkins, nainar ScribeNicks: fantasai, eae, fremy, TabAtkins, nainar WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 03 Aug 2017 Guessing minutes URL: http://www.w3.org/2017/08/03-css-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]