- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Mar 2016 19:27:21 -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.
=========================================
Recap of CSUN meeting with members of the APAWG
-----------------------------------------------
- Rossen gave the working group a summary of the requests and
concerns from APAWG.
- Their main complaint is CSS creates inaccessible content
when additional content is added, such as generated content.
- They were also concerned about content doing visual
reordering.
- The primary request from the group was to start work on CSS
AAM and the secondary request was to create a task force
to ensure that AAM progresses.
- The group didn't object to working on AAM, so Rossen will check
to see if the work is covered in the charter or if it would
require a re-charter.
- There wasn't any strong sentiment that a task force was needed,
though there was a suggestion that a liaison may help
communication.
- A decision on this will wait until the charter investigation
and further discussion on developing AAM.
Spec Updates
------------
- RESOLVED: Publish a new WD of Box Alignment with a note about
the default behavior when safe and unsafe is not
listed explicitly.
- RESOLVED: Publish new version of CSS Shapes
Comments on Serialization of calc()
-----------------------------------
- Rossen brought his feedback from Microsoft to the group and he
had three major concerns.
1) It won't be something they would want to spend time to
implement
2) Interoperability will be limited
3) Authors will find the simplification confusing
- TabAtkins was only on IRC, so discussion will continue on the
mailing list so he can respond.
Media Queries
-------------
- RESOLVED: Add defining a minimum for the onload property as an
issue in the spec.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Mar/0418.html
Present:
Rossen Atanassov
Tab Atkins (IRC Only)
Bert Bos
Tantek Çelik
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Brad Kemper
Ian Kilpatrick
Chris Lilley
Myles Maxfield
Thierry Michel
Edward O'Connor
Simon Pieters
Anton Prowse
Florian Rivoal
Alan Stearns
Ian Vollick
Steve Zilles
Regrets:
David Baron
Dave Cramer
François Remy
Jen Simmons
Lea Verou
Greg Whitworth
Scribe: dael
Rossen: I think we've given enough extra time. Hello everyone.
Rossen: Any extra items besides what I've captured in IRC which is
tantek request for updates and fantasai added one for grid
(https://lists.w3.org/Archives/Public/www-style/2016Mar/0345.html)
Rossen: Any additional items people want to request?
Rossen: I'll take that as a no.
Rossen: We'll add extras to the agenda if we have time.
Recap of CSUN meeting with members of the APAWG
===============================================
Rossen: This was a meeting with Mike Cooper and Rich from APA WG.
I wanted to give a quick update on that meeting and some
action items they have requested from us.
Rossen: The reason for the meeting was mostly from Rich and
Michael in relation to their concerns that CSS is evolving
at a rate they're having a hard time keeping up with and
things happening are potentially disruptive for a11y. In
summary their main complaint is CSS creates inaccessible
content when additional content is added, such as
generated content, counters etc.
Rossen: Those of you following a11y, this is nothing new. We've
spent most TPACs in joint meetings on this. Our message
has been the same, we have a spec describing how generated
content etc. need to be addressed for assistive
technology, CSS Speech, but no one is implementing it.
Rossen: The other complaint was one we discussed about a month ago.
Content and visual reordering.
Rossen: Again I restated that there is nothing new there and
content in the visual reordering has been a capability
since negative margins and abspos and whatnot.
Rossen: What do they want from us? In order to avoid formal
objections that are potentially going to be raised by IBM,
they wanted to work on CSS a11y mapping spec, which exists
for every other part of the platform. They want us to work
on a API mapping like that on CSS. That would let us
explicitly say generated content needs to do this to be
part of the a11y tree. Same with counters.
Rossen: Other thing they want us to work on is how visual order
can be made a11y to keyboard nav. I did push back on this
since visual nav is difficult. They want to see at least
an acknowledgment we're working on it.
Rossen: Last ask if there could be a joint task force between APA,
Aria, and CSS so this can be driven. I don't see how such
a task force can speed things up, but I'm putting this in
front of you so that if there are people who want to
participate in or create this task force, it's on the table.
Rossen: So in summary, asks are start work on API spec and joint
work with the task force.
<TabAtkins> Rather than a TF, just start up a spec in the WICG
about it?
Florian: One question on visual ordering. We talked about this
over and over. My impression is they have not as a group
acknowledged or understood our feedback that we thought
about this. Do you get the same feeling?
Rossen: We have talked and discussed and explained everything I
mentioned multiple times. There's nothing new here on our
end. Their requirements as far as I gather are in the same
place. Basically half the people want to nav visually,
half don't. They're hoping UAs will get together and
create both approaches.
Rossen: In my opinion this is a difficult ask and can't be solved
easily.
Rossen: So, yes, none of this information is new. The only more
formal ask is the work on CSS AAM spec which came up
during the last conference call fantasai and I attended to
speak about flexbox. We softly agreed on that phone call
that the spec can be done. Now we need to acknowledge that
and put text.
Rossen: My personal action was to recap all of this with the WG
and try to understand if there are objections to have CSS
AAM spec to be part of our charter so we can start working
on it.
tantek: A lot of these questions, as Florian pointed out, we've
answered in the past. We can probably do some digging and
find a DoC from a 10 year old CR that answers that. It
sounds the answers aren't easy to find, though. So if we
can get a discrete list of concerns we can put them in a
FAQ so that we make it clear that we do care and we are
listening and if we have answers we can point people to
them and iterate where there's confusion
tantek: It's come up frequently enough that it deserves an FAQ.
tantek: I'm not sure how else to move forward on this
communication issue.
fantasai: We have 2 things in queue. There's clarifications to
flexbox based on that conversation with a11y. dauwhe and
I have been working on an update to generated content to
make it easier to find these things are in.
hober: Rossen you were trying to ask if we can add CSS AAM to the
charter, right? Do you believe the current charter covers
this, or do we need to recharter?
Rossen: Depends on if there's a joint TF that we take on. It would
be the TF charter to come up with AAM. I don't think we
need to recharter because a11y is part of our charter.
Florian: Yeah, do we need a TF or do we need a liaison?
* fantasai prefers latter
Rossen: I believe either are fine for them. Either of those will
be more than what we have.
Rossen: I think they'd be happy with them.
Florian: Another comment. I have no problem about the group taking
on the spec work, but I reject the framing that this is
necessary to not object to flexbox.
Rossen: I wouldn't hold flex up for this. If formal objection
needs to be raised, I told them to raise it and we'll deal
with it as we would with anything.
Rossen: So we took 20 minutes. It was my action and obligation to
take this up with the WG. If we're okay to add this to the
charter, I'll go and read through the charter to see if
it's covered, but would there be anyone objecting?
<tantek> +1 on adding it to charter explicitly
Rossen: I don't hear any. So we can start on CSS AAM. As for TF or
liaison, a more formal relationship, we'll defer and do if
the need arises.
Rossen: We have MQ, Values, and the extra items on grid and spec
updates on the agenda.
Spec Updates
============
Rossen: tantek you wanted to put this on with some specs?
tantek: I have specifics. Let's do this easy half and then hard
half. I'd like to propose CSS Masking, Box Alignment, and
Values and Units updated WD. Most of those are at least a
year out of date. I know we've resolved previously, but
we've had edits since. I think they're good enough to
publish. If we agree that empowers the editors to publish,
even with outstanding issues.
tantek: So I propose that the WG update CSS Masking, Box
Alignment, and Values and Units.
fantasai: Masking and Values and Units are CR.
tantek: Sorry, I misread that.
fantasai: I'm planning to republish Values and Units anyway, but
we're waiting on a solid review of the calc() because
that's new.
Rossen: And we have a topic on it today.
tantek: Okay, I appreciate the correction. So revised to publish
an update to CSS Masking.
fantasai: Also in CR.
tantek: Box alignment
fantasai: I'm happy to take an action to prepare a publication in
the next few weeks, but I want to check for edits that
need WG resolutions.
tantek: Since it's a WD I'd rather just publish and we can publish
again with more edits. Since it's a year out of date, I'd
like to publish as-is.
tantek: I don't want to stop energy on things a year out of date.
fantasai: Okay. There's one issue I want recorded which is the
default behavior when safe and unsafe is not listed
explicitly.
tantek: I'm absolutely for capturing the issue.
Rossen: Is this discussed on the ML?
fantasai: I haven't completely thought it through. I want it noted
as an issue that may change.
Rossen: It would be good to capture your personal concern. So
objections to publishing a new WD of Box Alignment?
<tantek> PROPOSAL: Publish CSS Box Alignment Working Draft with
noting issue raised by fantasai
<ChrisL> +1 to publish
RESOLVED: Publish a new WD of Box Alignment with a note about the
default behavior when safe and unsafe is not listed
explicitly.
<ChrisL> fantasai, if that spec is ready to go by Monday I can set
it up for Tuesday, otherwise it will be Thursday
tantek: Harder proposal is we have a number of CRs that are long
out of date. I have to thank fantasai for reminding me to
look at this. So there's three CRs CSS Masking, Values and
Units (which as fantasai noted calc() needs review) and
CSS Shapes
<fantasai> V&U is on my list :)
tantek: Shapes is a year out of date, two years.
Rossen: I don't think there's anything added.
tantek: It was edited as of Jan 31 this year.
fantasai: Formatting and linking fixes, you need to look at change
log to see if it was substantial. We should get
resolution if needed
Florian: I don't believe we've done anything substantive in Shapes.
<ChrisL> linking fixes are good
astearns: There's edits resolved in November that I haven't done.
It makes sense to do those and then republish.
Rossen: At least for CSS Shapes, let's record a resolution. For
the rest, fantasai I think you were editor.
fantasai: V&U we're waiting to resolve all the issues and have a
DoC. That's on my list. Masking I don't edit. We did
resolutions in Sydney and we should have those in the
draft and bring them to the group.
tantek: Normative?
fantasai: Yes.
Rossen: Sounds like these aren't ready, but on the way.
tantek: V&U is a topic later on the call, Masking I'm worried
because it's more than a year out of date. I know there
are pending changes, but why wait?
fantasai: Publishing a CR takes a lot of process. We need a DoC
and if there's nothing to put it's not worth
republishing. I don't know if there's normative changes,
they could just be editorial. The normative changes from
Sydney are quite significant.
tantek: I'd like TabAtkins' opinions on that too since he wasn't
in Sydney.
fantasai: We've renamed a keyword and that needs to be ASAP.
ChrisL: If there are normative changes we need a DoC. There has to
be a meeting and the less it looks correct the longer it
will take.
<TabAtkins> What needs an opinion from me?
tantek: TabAtkins it's the pending normative changes in CSS
Masking because we resolved on those when you're not there
in Sydney. So 1) are the changes good with you? and 2) if
so is there a rough estimate of when you'll apply the
changes?
tantek: So we can do a CR with a DoC including those changes.
tantek: I'm fine waiting, I just want to know the next steps.
<TabAtkins> Ah, I have no clue what those changes are, so I'll
have to review all of them. ^_^
* TabAtkins has the entire Sydney minutes in his backlog.
Rossen: While we wait on TabAtkins are these specs of interest to
you because the dates, or is there anything else?
tantek: Both the dates and these are implementations priorities
for us, at least parts. That's my filter for bringing
these up.
tantek: So it's implementation request, not just busy work.
Rossen: That's fair.
Rossen: TabAtkins says he has no clue and has to go and review.
That's your answer. So we can't resolve for that today.
tantek: We got box alignment and shapes. We have to postpone
masking until TabAtkins does minutes and V&U is coming up.
I can bring it up again in a week or two.
Rossen: Sounds good.
Rossen: Objections to publishing box alignments and shapes?
Rossen: Let's call it resolved.
RESOLVED: Publish new version of CSS Shapes
* tantek thanks Rossen for bumping up republication in the agenda
Comments on Serialization of calc()
===================================
Rossen https://lists.w3.org/Archives/Public/www-style/2016Mar/0369.html
Rossen: This was about adding simplification to serialization for
calc(). I wasn't here last week but I can update our
position. I guess one question was when we are defining a
simplified serialization what does that mean?
<Rossen> calc(9px + 8em)
Rossen: If I have something like ^
<Rossen> 9px + 8em
Rossen: It should output as ^?
<Rossen> calc(9px + 8em + 5px + 3ex)
Rossen: The first question is if I have something like ^
Rossen: what is that serialized as?
Rossen: Are all of them folded and computed to minimum possible
types? Or only adjacent?
Rossen: It's not clear to me what the ask is. And it's unclear how
this makes it easier for authors to enter a random calc()
and make sense of it during debug.
<glazou> +1 to everything what Rossen said
Rossen: I'm kind of uneasy
ChrisL: That's a good question on debug. If people type in 4
things and find 3 they'll find it weird.
Rossen: Reading the e-mails it seems like it was this is what we
do and it seems easy so we should do it. I don't see how
it helps ergonomics. That was my feedback that was
requested of us. At this point we're mostly against this.
* fantasai thinks she agrees with Rossen's position here as well.
glazou: In general, I agree with everything you said. In general
if you change what an author specified the author will be
lost when you try and debug or make edits because you
don't find what you authored.
glazou: We used to have a basic principal to avoid touching things
the author specified. I know it's not always feasible but
in general we should try and reach that goal as much as we
can.
* tantek wonders if there's a tension here between
canonicalization and author-text preservation
<tantek> AKA debugging
Rossen: On our end we go to great lengths to keep all author spec
stuff for debugging. The serialization in this case is
lost. If we have a lossy serialization who knows what's
happens.
Rossen: As to my point as to what are we combining, that will make
it hard on the testability side. I don't want to have a
whole bunch of new ways for browser detection because
someone figured out how to use calc() to probe different
serializations.
<TabAtkins> Oh my god, this wasn't supposed to be re-litigated. We
were just waiting for MS to make sure our tentative
decision was implementable on their end.
<TabAtkins> It is. End of story. Let's resolve the tentative
decision we made last week.
Rossen: There's no one on the queue.
Rossen: I'm reading TabAtkins replies on IRC.
Rossen: I'm not sure I read TabAtkins right. He says we don't want
to re-litigate this decision from last week that was
waiting for MS and now that I am speaking on their behalf
and I'm expressing concern it seems TabAtkins doesn't want
to take this. Again, I wasn't here. Was there a resolution
last week?
dael: There wasn't.
Rossen: Okay.
<TabAtkins> There was no resolution *because Greg asked me to make
sure it was implementable by y'all*.
Rossen: If it wasn't my position is not not simplify serialization.
Rossen: If this needs more baking time I'm fine to go on the ML
for this discussion.
Rossen: I don't see or hear any push back. It looks like
TabAtkins ....
ChrisL: TabAtkins seemed to say there was a tentative resolution
but gregwhitworth wanted more time to check.
<TabAtkins> :(((((
Rossen: And I did. I'm the implementor in charge of this and I
have 3 push backs. 1) this won't be a trigger for us to
implement 2) interop will be flaky at best and 3) this
isn't helping authors. It's going to be hard for tools.
<TabAtkins> What is this about "flaky interop"???
<ChrisL> That makes sense
astearns: The last point on helping authors wasn't part of last
week's discussion.
Rossen: Okay.
Rossen: I don't believe we can resolve without TabAtkins on the
call. I'd like to continue on the ML
Rossen: We'll bring it back next week.
<TabAtkins> arghgaldsg;s
<astearns> TabAtkins: I think the main point is that the
discussion last week talked about *whether* we could
simplify, but not *why* - Rossen is arguing that it's
not author-friendly to simplify
<TabAtkins> And I *definitely* talked about why to simplify.
<TabAtkins> I'm typing up an email right now.
<ChrisL> florian, rossen - I'm at a conf next week so if we can do
the color MQ this week that would be helpful. I have
opinions on the questions posed
Media Queries - Scripting
-------------------------
Florian: This has 3 values. none, interact (suggested to rename)
which is normal scripting, and onload which is when they
run normally but have something that stops it. One
question was should we be explicit about a minimum amount
of time that things need to run before you can be onload?
Florian: TabAtkins said be fuzzy on time, fantasai says make it
explicit. What do others think?
Florian: Nothing...
Rossen: Apparently not enough traction
Florian: So the idea for having a minimum is that if you use it
you want to rely on it for some things. So you want to
know an event will fire. The alternative from TabAtkins
is that determining which threshold is hard, but looking
at it by the UA is easy, so let's not invent problems and
keep it fuzzy for now.
smfr: Do we know what Opera mini and UA do in printing?
Florian: Opera mini I remember in a faint way...It does a combo of
go at least as far as an onload and let the scripts run
out as long as they do in a time frame. If not, send the
results to a thin client.
Florian: For printing, I'm not sure.
zcorpan: I think Opera mini does the timeout even if you let
scripts run. So it's interacting for a bit, but if you
interact after 5 minutes, you reload the page.
smfr: Seems like we should keep it fuzzy. I don't see how to spec
this.
fantasai: Should we set a min so that the author can rely on at
least this has happened.
smfr: Min seems to be you get a load event for the main resource.
fantasai: That would be useful to put in the spec so someone
doesn't decide as soon as the script loads we're done.
zcorpan: What's the printing scenario?
Florian: So can you do XHR once it loads, or do you assume there
is no scripting engine and all content must be done
server side? Can you use Houdini to do your layout?
<Bert> (Both Prince and PDFReactor use JS on load to allow things
like making ToCs or filling in subtotals on tables)
zcorpan: Do you know of an app that would benefit from scripting
on an onload?
Florian: Yes, I think...If you know you're not going to have
long-term running scripts you shouldn't set up handles
for users to interact with and have scripts respond. But
this is different than no scripts because the scripts can
be used to layout the doc or content manipulation.
<zcorpan> i still don't understand the use case
<TabAtkins> zcorpan: The use-case for (scripting) in general?
<zcorpan> TabAtkins: the difference between on and onload
<TabAtkins> It means you can apply CSS that depends on JS working
early, but shouldn't apply CSS for anything that would
require JS to be running continuously.
Rossen: So Florian what do you want from the WG?
Florian: Are we happy to leave as is without an explicit set of
requirements for a minimum of what you must run for
onload or to we want to spec a minimum?
smfr: Does anyone care for impl?
fantasai: It would help for testing, otherwise what do you test?
smfr: Yes, but does anyone impl this MQ?
Rossen: We don't.
fantasai: I would be mainly opera mini and printing engines.
Florian: For Vivliostyle, we don't implement media queries yet,
but we will soon and first would be onload.
smfr: Given the level of interest I think we have to leave it fuzzy.
Florian: On the ML we had a proposal that says you should go as
far as loading the DOM Content. I'm okay with either, but
if we don't write anything it's hard to test.
<fantasai> I think it's useful to know if events fire at all, or
if you only run inlined scripts
iank: I think we need real-world feedback on this. I don't think
there's a strong need to define it at this point.
Florian: I'm okay with that. fantasai?
fantasai: I'd prefer if we had a minimum bar which is you do all
the scripts before onload or something. I don't care
which, it can be conservative, but the author should be
able to rely on something happening. Like do I have to
do everything in an inline script? That would be useful
for the authors to know when I'm working with this kind
of media, I can position my scripts so they run
fantasai: UA do all kinds of things because they're not targeting
things like the script is only running for a part of the
time. We're creating a MQ so the author can say what
situation I'm in. If we don't tell them what they have
to do to get their scripts to run that's not as useful.
The impl won't care because they can do more. But for
the authors it's useful to know if I put my script in
this way it'll run. We need a boundary so they know what
to target
<tantek> tends to agree with fantasai
<tantek> re: sympathizing with the model for the user
Florian: I agree it would be useful for what you say. But given
that we have limited UA experience should we wait?
fantasai: If we don't have information we should ask for it. I
think this is an open issue in the spec until we have a
minimum. I want guidance for authors.
<tantek> I'd prefer to keep it as an open issue on the spec as
fantasai described
<tantek> and frankly, publish with that explicit open issue
Rossen: It sounds like you have preference for defining in this
way. Implementors are saying we don't know until we play
with it.
fantasai: We don't have the right implementors on the call.
Rossen: The implementors on the call who might implement this
can't say this is easy to decide before we try.
Florian: We're not proposing a definition, we're setting a minimum.
I wouldn't be comfortable giving a max, but if we set a
min that's fine. We'll probably do more, but we'll do that.
tantek: I don't think we're going to come to consensus, but we
agree there's an issue. I propose we capture the issue in
the spec and then do a new publication.
Florian: tantek that's why we're going through these issue is to
publish.
tantek: So we should capture the issue. I don't think we'll
resolve on the call. Capture as an issue and iterate it
there.
Rossen: Is everyone okay with an issue?
fantasai: I'd like it marked as an issue and the editors take an
action to contact people who would implement this and
find a minimum.
RESOLVED: Add defining a minimum for the onload property as an
issue in the spec.
ACTION Florian work with print related impl to find the best
minimum for this MQ
<trackbot> Created ACTION-762
<ChrisL> won't be on the call next week (web audio conference) but
wants to discuss the color one
Rossen: This is the top of the hour. We have 3 MQ topics left. One
was requested by Chris, color-gamut. Was there anything
you needed captured?
ChrisL: First is that I agree 'display' is correct term. Second,
this should be restricted to RGB devices because that's
current implementor need.
Rossen: I'm not opening for discussion, I just want to capture
Chris's thoughts since he won't be here next week.
Florian: I want Chris's opinion, but a more productive way to
capture them is...TabAtkins edited the spec. I'd like
ChrisL's opinion on the latest version.
ChrisL: I'll do that on the list.
Florian: I do want your feedback.
Rossen: Thank you all. That takes us to the end of this call.
Received on Wednesday, 30 March 2016 23:28:19 UTC