- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Apr 2016 19:50:06 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Test suite metadata
-------------------
- The test submission process is being reviewed in hopes of making
the tests more useful to more people.
- The discussion began around where on the spectrum from the
current metadata status and no metadata should the working
group land.
- It was expressed that the first step should be remove the
pieces everyone agrees should be removed and see how much
progress can be made.
- Tests should be accepted if they contain the important metadata,
even if some of the styling is off with a request to fix the
problems on the next bug.
- From there, the conversation moved to the build system being
another thing obstructing tests.
- There was general agreement that the build system as it
stands now isn't needed, though there will still need to
be metadata left in to get which tests apply to which spec.
- gsnedders will do the work to remove the build system and
see what progress that creates on testing.
- Discussion on testing will continue on the mailing list.
Round Display
-------------
- RESOLVED: Add 'viewport-fit: contain' to Round Display spec
- The description of the 'viewport-fit' property will need to be
clear about the order it occurs in with other properties.
- The group liked the idea of having an additional attribute
returning shape of display, however this information isn't
currently exposed to the browser.
- Until the device shape information is available, Florian
will continue working on the media feature he is building
to return if a device is round.
Planning the CR/PR of CSS2.2
----------------------------
- Bert will continue looking through the errata for test coverage
and report back to the group once he's done.
Grid
----
- RESOLVED: Accept grid issue 26; adopt the language in option B
on this e-mail:
https://lists.w3.org/Archives/Public/www-style/2016Jan/0063.html
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Apr/0228.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
Daniel Glazman
Tony Graham
Jihye Hong
Dael Jackson
Brad Kemper
Ian Kilpatrick
Chris Lilley
Peter Linss
Myles Maxfield
Edward O'Connor
Anton Prowse
Matt Rakow
François Remy
Florian Rivoal
Alan Stearns
Geoffrey Sneddon
Ian Vollick
Regrets:
Simon Fraser
Scribe: dael
Test suite metadata
===================
Rossen: Let's go ahead and get started
Rossen: Any additional agenda items? [silence]
Rossen: Was this added by gsnedders?
astearns: I added it because gsnedders asked the group.
Rossen: gsnedders are you capable of handling this for the week?
gsnedders: I presume most of you have seen the mailing list
discussion over the last couple of weeks. A lot of that
comes down to tension between making it easier for
browser vendors to contribute tests vs having more
metadata which makes it easier for others.
gsnedders: The question is where to go on that spectrum.
Florian: I think even if we want to go far, we don't have to go
all the way on the first step. We can remove the first
hurdle and see where that gets us.
Florian: I'd be in favor of removing everything people agree on
and move on later.
Florian: I'm not sure there's a browser vendor vs everyone else
characterization because hopefully the browser vendors
won't dump the tests, but also will pull from the same
place. Even if they don't have metadata in their repo
there may be implicit information like who committed the
test that means that even if the tests don't have
metadata, it doesn't happen that one browser has a bunch
of new tests which has a lot failing...if that happens
they won't integrate the tests if you can't see where
they're from.
Florian: Some data is useful for browsers, as a browser vendor.
But we need to reduce.
<tantek> any chance for collaboration? crowd-sourcing the metadata?
dbaron: I think one of the issues...people might be not so much...
that we ask for a bunch of stuff, but that the people who
review tests are very picky.
dbaron: Sometimes the right way to deal with it is say we want
tests and like metadata, but you just wrote 500 test and
we won't make you go back, but next time can you do this
stuff. That's a reasonable thing to say sometimes.
Florian: I think we are too picky in general and when people
submit tests and they've valid and it's stylistic that
should be allowed through. When the metadata lack makes
it so you don't know what it's for we can't accept it.
<fantasai> Florian++
<tantek> is there a tl;dr summary of the mailing list thread?
Florian: Also mentioned on the ML more than the metadata, but the
build system might be a hurdle. We might try and remove
that.
Rossen: Other opinions?
<dbaron> yes, I think having a build system is a hurdle
gsnedders: When it comes to the build system, my understanding is
there were a few people in the group who wanted to
build test suites per spec which requires a build step.
It could be no one feels that way anymore and they're
happy to be able to extract a list of test applied to
this spec and we don't need the build system as exists
today.
Rossen: Some degree of reference between tests and parts of specs
is required so we can have the organization of spec
progress and track what is covered. Especially when specs
are close to REC. Anything other than that...I'm not sure
is necessary.
fantasai: I don't think we need a build system. There were
historical reasons, but they don't really apply today.
Most tests can be run in place. There's nice things you
can get from a build system, but I don't think it's
needed to run the tests. Even right now tests are ID by
the file name, not build information. So I don't see why
vendors would need to use the build information. There's
a few XHTML will need to be fixed.
<ChrisL> we don't really need xhtml versions of tests. we do need
the manifests.
plinss: The build system is generating HTML and XHTML which was
needed before, but I'm not sure anymore. It also gets us
the manifests which is needed. It's not something we can
walk away from unless we rework architecture.
<tantek> I'm in favor of dropping the XHTML versions for any CSS3
or later test suites.
gsnedders: If we have a manifest for the whole repo, if we have a
way of getting which tests apply to which spec, that
suffices for the infrastructure, does it not?
plinss: We can make changes to the test harness to change manifest
formats if that's what we want. The thing the test harness
gets us a lot of good info to get a spec out of CR. It
gives us a lot of information about where tests are needed.
I don't think we want to walk away from it as long as we
get benefit.
fantasai: What we do on our end for the build system doesn't
matter to the vendors. They can run tests in place. Now
that we accept HTML we'll need to switch a few on the
source format.
plinss: I agree.
fantasai: And for our purposes we can keep it unless we replace
that functionality.
<ChrisL> agree we really need spec and reference links
<astearns> I propose we have gsnedders take the result of the
build/metadata conversation so far and edit the wiki on
how to submit and review tests
<gsnedders> astearns: we also have some things pointing to TTWF.
we should just have the wiki link to that in its
entirety.
plinss: If we're the only ones running the build system, we do
need some metadata. Differentiate tests and references and
the spec links. Other than that the build doesn't care
about metadata
Rossen: And you're suggesting this should be on us or the vendors
submitting tests.
plinss: I think people submitting tests tell us what spec and what
section.
Florian: We've been discussing this on the ML. One case is the
simple is where test points to one part of a spec. The
complex case is when a test points to multiple specs. In
the first case having a directory structure that matches
the spec could be enough and we leave the links as
possible if people want more complex, is that good enough?
plinss: Directory structure is metadata.
Florian: It's less annoying to type according to most people.
fantasai: I think it's important to have detailed info as to which
part of a spec is being tested. If it's really
troublesome to put in the help links than we can do the
primary link auto. But once you're writing tests for a
section we can have directory structure and the help
links and then you can copy from previous tests. We
could go either way on that. I think we should keep the
help links because tests must test multiple sections.
fantasai: We have concerns about too many tests in one large
folder. If it helps to split that's a good idea. If it
helps to have a direct link we can build that in as well.
We have to keep a strong directory structure and vendors
will have to map it.
fantasai: There was one concern where if you have a directory
structure you don't have to worry about spec links
breaking and that's not really an issue. We move the
sections, but we maintain their IDs.
Rossen: Is there are this point...it sounds like we agree we need
the metadata in one form or another continuing forward at
least for specs going in and out of CR to be able to track
what's covered.
Rossen: The implementations details we can continue to debate and
improve on.
Rossen: I want to go back to gsnedders and make sure your
questions are addressed.
gsnedders: I think they are.
Rossen: With that said, is there anything else you want out of
this gsnedders?
gsnedders: Not immediately. If I take an action to get rid of the
build as we have it and see where that leaves us....
fantasai: The only thing to make build optional is fix HTML tests.
gsnedders: And build a manifest for everything to run the tests
without building.
fantasai: There were a few tools we wanted...a linter.
gsnedders: If we get rid of a lot of the build system we slowly
rewrite until we have that.
fantasai: A tool that can run in place and link the manifest in
place.
plinss: That's fine by be but there's code per spec manifest as
well.
Rossen: We can continue to get details on the ML.
ACTION gsnedders get rid of the build as we have it and see where
that leaves us
<trackbot> Created ACTION-766
Round Display
=============
Setting the viewport into non-rectangular display
-------------------------------------------------
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Apr/0066.html
jihye: We discussed the robustness of CSS.
jihye: In general the viewport takes the shape of the display. So
the corners get clipped when it is displayed on round. So
the idea to solve this is setting the viewport as the
inscribed square. A think a new descriptor can do that.
jihye: I suggest a new one as 'viewport-fit' that has a value as
'contain'.
jihye: Florian suggested to add 'cover' and 'auto' value. 'Cover'
would have the viewport as the bounding box of the display.
Florian: That's one place I disagree. We need to have two values,
or else it's not a switch. There's 'contain' and 'cover'.
The default if we ignore auto is 'contain'. So they have
everything visible and there's no disappearing content.
'Cover' should be used by authors who know how to deal
with it.
Florian: I'm adding an 'auto' value that is the same as contain
with some leeway. So having a strict rectangle makes it
smaller than needed. A rectangular screen with slight
rounding it's not that bad to miss a part.
Florian: It's similar to contain with some leeway. I don't know if
it's essential.
Rossen: It sounds too magic and I can see a lot of cases where
it's unpredictable.
<TabAtkins> My office is being loud right now but: I don't think
we should 'contain', by default or at all, really. It
hides a ton of the screen on a round display.
<TabAtkins> Like, I think the "some part of the viewport is
hidden" problem is *less bad* than "the screen has
huge gaps on each side and is really tiny" problem.
fantasai: We talked at the F2F about a UA might want it larger
than the contained rectangle by an amount and use the
scrolling to let the user see the corners. So you do a
circle and have a slightly bigger rectangle the user
could scroll down. That would be reasonable to want by
default. Whatever we have as default should allow that
thing and let the UA be more intelligent.
Florian: So do you agree with 'auto', 'contain', and 'cover' with
more magic on 'auto'?
fantasai: Yes.
Rossen: How does scrolling or panning or refitting the visual have
anything to do with size of them. You're describing two
orthogonal features.
Florian: They're not orthogonal. 'viewport-fit' does two things.
If we go with the device orientation spec it sets the
size of the layout viewport before you apply @viewport
rules.
Florian: The 'viewport-fit' switches that size being the one that
covers and fits in. The other thing is about the visual
viewport. Its size must fit in the screen and you must
place it tin the screen.
Florian: While we're speaking about size and position of visual
viewport, having wording that says it must not be
strictly in the middle doesn't sound insane to me.
MaRakow: You might have partially answered my question, but I'm
trying to figure out exactly the implications in terms of
how this enters into calculating of used layout viewport.
Especially when using width and height properties. What
are those relevant to at that point. I'm not sure a
'contain' is simple to calculate. Such as a rounded
rectangle you could favor vertical over horizontal you
could expand or have a perfect square.
MaRakow: It might be interesting to rephase instead of a fit rule
it's about controlling the initial viewport.
MaRakow: Also it interests me what it would mean to expose
negative coordinates so you could see less than 0 on x
and y. I'm not sure what that would do or if we would
have compat issues. We should think that through.
Florian: I think what I had in mind was more blunt than what you
described. The switch between 'cover' and 'contain' it
wasn't enough power for the author to control a long vs
tall viewport to meet one end. It was set up two shapes,
one that covers the whole screen and one that fits in it.
It's not as flexible. Maybe we want that flexibility.
MaRakow: Even if you don't offer configurability, maybe it's not
having rounded rectangle but it's circular.
Florian: I agree the email is too short to be a full spec, but in
general where that rectangle is is up to the UA. As long
as you pick one in the screen you're good. If you pick a
silly one, that's bad UA. If there's multiple you as a
browser do what you think is best.
<fantasai> probably want to recommend 'contain' being the largest
possible rectangle that would fit
<fantasai> bias to landscape
<MaRakow> bias to larger dimension?
Rossen: So in summary...it sounds like we agree on the three
values. Is that correct proposal?
Florian: It's my proposal at least.
jihye: Yes. I have something of interest...there are descriptors
about specifying the builders like height. How the priority
will be? I think viewport-fit is higher priority over height.
Florian: I think so too. I think the spec currently lacks vocab.
The space in which the viewport is...which screen do we
use? The one that fits in or fills and once you pick that
you have all the other rules. Once you pick contain you
can pretend the screen isn't round at all.
Florian: We need to be careful when writing that we make that
clear, but that's the intention.
<BradK> Can the visual viewport not clip the content that falls
between the contained visual viewport and the actual
device edge?
jihye: OK. Can I do the spec about the 'viewport-fit' in round
display first?
Florian: I think it would be...the problem would be there is
missing vocab in device adapt spec. It would be better if
we had some terms there.
Florian: I think it makes sense in round-display for now and if we
discover missing terminology that should be elsewhere we
add it there and you refer to it.
MaRakow: I'd be curious to see what the text looks like. It's hard
to evaluate without text. But if it becomes a rule for
initial viewport it might make sense to move it to device.
Rossen: Let's start with the proposal added to round display.
We'll have text and go from there.
Florian: Yeah. I think it'll eventually migrate.
Rossen: Let's decide once there's text.
Rossen: In that case, any objections to proposed addition of
viewport-fit: contain added to Round Display spec?
RESOLVED: Add 'viewport-fit: contain' to Round Display spec
Additional attributes returning shape of display
------------------------------------------------
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Apr/0110.html
jihye: The device radius in CSS Round Display detects the shape of
the display it enables us to apply different styles
according to the display shape. We still need to know the
device shape when we implement apps with JS. For example
scrolling is JS. So it's necessary to detect the shape of
the screen.
jihye: For example, in ??? there is a JS to detect if the shape is
round to support round display. CSSOM view has information
about the output screen device.
<jihye> https://www.w3.org/TR/cssom-view-1/#the-screen-interface
jihye: So I think it can also give info about the shape of the
screen. It returns true when rounded. With this attribute
we can know the shape of the display.
Rossen: Comments?
<TabAtkins> I agree that directly exposing the shape is good.
Rossen: Suggestions?
Florian: I tend to comment on round-display, but OM View is out of
my area.
Rossen: As an API having this as a boolean return true when
something is circular sounds wrong to me.
Rossen: You want the API to return the shape and then it's up to
the author. If you want more boolean feature it's more of
a media feature and should be dealt with that way.
fantasai: I think I agree the API should return a shape, but it
can return false for a rectangle. That was you use as a
boolean and get shape.
Rossen: And a rectangle with 0.1 rounding, is it a rectangle?
Rossen: If we can avoid we should.
Florian: And true and false to MQ?
Rossen: Yes.
Rossen: Any other feedback?
Rossen: So is there anyone objecting to adding this to the OM view?
Florian: I have a question. Last time we talked about this we
discussed at the OS level you don't know the shape. So a
boolean we can do, but the shape being returned isn't
available to the browser.
Rossen: I'm not sure I follow.
Florian: So an API that returns a shape for not-rectangle and I
think last time we talked about this someone mentioned
that this isn't typically made available by the OS. At
the OS you can have a boolean returning round. If that's
the case we can't do this API
fantasai: Can we do boolean now and expand later?
Florian: If we just do boolean, why not have it as a MQ? What does
it get us over a MQ?
fantasai: Fair point. We should wait until we can implement the API
<tantek> +1 to that
Florian: Maybe I'm wrong, but I thought last time we discussed we
couldn't.
Florian: I think it was Android that did something. It is just am
I a circle.
Rossen: And once they support more they'll have to add.
Rossen: In that case I'm siding a lot more with keeping this as a
MQ if we need boolean. And later add a feature for
geometry when it's available.
Florian: And I'll work on media feature this week.
Rossen: And so we need no new resolution because Florian has an
action.
Rossen: jihye did we miss anything?
jihye: I want to add something. If I understand correctly I
suggested an attribute that returns information about shape
of display. It returns the boolean value...
Florian: What we're saying is there's 2 possible APIs. One that
returns a boolean that says if I'm a circle and that's
not needed because I'm writing a MQ for it. The other one
returns information of geometry of the shape and that
would be useful, but the OS doesn't give the browser that
info and that can't be done.
jihye: I thought of one that would return the coverage of the
corners. That can't be implemented?
<joone> I think Android wear only has the api for checking the
display shape whether it is round or not.
Florian: As far as I know, OS as of today have no API to inform
the browser, or have extremely basic that just say I'm a
circle. I'd like someone who knows more about this. But
at the F2F I think we said that Android is the only one
that gives you anything and it's a boolean.
Florian: If we get more than that we can do the API.
Florian: Can someone take an action on checking?
Rossen: It sounds like that would be a good action for someone
close to Android.
Rossen: We have members from Google. Or jihye if you have
implementor experience and can check with engineers that
would help.
Florian: Can we action OS vendors to see what their OS offers?
myles: Ours doesn't offer anything.
Rossen: I'm pretty sure ours doesn't offer anything.
Florian: If anything it's android.
Rossen: So currently they have the boolean, as per our current
understanding.
Rossen: With all that information, is there anything else to cover
on this topic jihye?
jihye: No.
jihye: I think we discussed about all the things.
Rossen: Thank you
Planning the CR/PR of CSS2.2
============================
Rossen: We have 6 minutes. 1 flex, a number of grid, CSS OM View,
and CSS 2.2. Out of these...bert are you on the phone?
Bert: Yes.
Rossen: Is 2.2 this week?
Bert: It's not that urgent. If people have advice...there's 3
questions on this. 1) Testing: how many? what do we have? 2)
What is the next version of 2.2, do we need a new WD? 3)
What time scale is reasonable...end of summer, before?
Bert: If there's time for that today sure, but it's no hurry.
Rossen: I'm bringing this up because I know plh had some concerns
on this and we want to make sure this is on track and we
have a good plan to move us from 2.1.
Rossen: With that said, back to your questions...testing.
Everything in 2.1, how much change is there so we need
test coverage?
Bert: I haven't checked everything. I looked at the errata. Some
are informative. Some are normative and have tests. I found
a few that need tests. I expect we need a handful more tests.
I've made less than 10. I haven't checked all of them yet,
though.
Bert: So far a handful of tests is needed. The ones I tested were
impl already so I don't expect trouble with impl. But I
haven't checked them all if others know more.
Rossen: I know you and antonp were handling the errata.
Bert: Yes, there were some complex issues with margins and boxes.
So I'm trying to test those. It's hard to say how much time
it will take.
Rossen: Sounds like you need a bit more info before we can decide
on how much testing is needed. Why don't you come back to
us with that information?
Bert: That's fine. I'll have something next week or week after.
Rossen: Thank you.
Grid Issue 26
=============
Rossen: I'm fine on that one. I agree with the resolution.
RESOLVED: Accept grid issue 26; adopt the language in option B on
this e-mail:
https://lists.w3.org/Archives/Public/www-style/2016Jan/0063.html
astearns: We're at the hour.
Rossen: Since we're at the top of the hour, let's call it meeting adorned.
Received on Wednesday, 13 April 2016 23:51:07 UTC