- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 17 Sep 2015 07:06:13 -0400
- To: www-style@w3.org
TPAC & Associated Events
------------------------
- Everyone was requested to add items to the TPAC agenda so that
scheduling can be handled in advance.
- Anyone planning on attending the Japanese Industry Meet-Up on
the Sunday before TPAC was asked to please add their name to
the wiki as well as any topics they'd like discussed. The
start time and agenda will be announced shortly after a venue
is decided upon.
- Lastly, anyone looking to attend the Monday evening developer
meet-up at TPAC was reminded to sign up.
Prefixing Policy in Snapshot
----------------------------
- Apple and Microsoft are still reviewing so the language couldn't
be finalized.
- Apple had some preliminary feedback that lead to further
conversation about the word 'unstable' in section 3.2.3.
Market Pressure and De Facto Standards.
- fantasai will further clarify the word 'unstable' and
perhaps use an alternate word.
- The feedback also lead to a conversation about doing a better
job making the case as to why the prefix policy change is good
for implementors.
- Florian will write up a note with the rational which he
summarized in the call by saying: "vendors can remove the
prefixed version once the bugs are ironed out because
there will be no risk to compat by removing the prefix
because everyone also used the unprefixed version."
Writing Mode Issues
-------------------
- RESOLVED: Replaced sizing remains physical. Add an appendix
about the consideration of the security and privacy
concerns.
- The authors plan to ask for a new CR publication as soon as next
week so if there are any outstanding issues, please add them now.
Definition of White Space
-------------------------
- RESOLVED: Add the form feed character (U+000C) and make sure all
CSS specs align on the definition of white space.
Using Prefixed Examples in Specs
--------------------------------
- The group agreed that they wanted cases like Florian's to be
able to use a prefixed property in a spec example for what
behavior should look like when implemented however the ability
to do this is a W3C level decision so plh will discuss it with
the appropriate parties.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
Bert Bos
Adenilson Cavalcanti
Tantek Çelik
Dave Cramer
Greg Davis
Elika Etemad
Simon Fraser
Koji Ishii
Dael Jackson
Brian Kardell
Toru Kawakubo
Brad Kemper
Philippe Le Hégaret
Michael Miller
Edward O'Connor
Matt Rakow
Florian Rivoal
Hiroshi Sakakibara
Alan Stearns
Greg Whitworth
Regrets:
David Baron
Daniel Glazman
Tony Graham
Peter Linss
Anton Prowse
Lea Verou
Johannes Wilm
scribe: dael
astearns: We might as well start
astearns: Any extra agenda items?
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Aug/0333.html
Florian: If we have time we might want to look into this e-mail
above. Tantek and I responded about allowing resize to
apply to replaced elements.
astearns: We'll put that at the end.
TPAC & Associated Events
------------------------
<fantasai> https://wiki.csswg.org/planning/tpac-2015
astearns: We need agenda items for TPAC so please go to the wiki
and add things you want to discuss. The sooner we items
on the sooner we get a schedule so we don't have to
spend F2F time scheduling
<fantasai> If no items, we will do a dramatic reading of CSS Box
Alignment
<fantasai> So add items
<fantasai> :p
<astearns> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JulSep/0168.html
[Member Only Link]
astearns: Also, just reminding everybody about the Japanese
Industry meet-up. Please add your name to the wiki
saying you're going.
skk: I'm trying to decide the venue. Then I will note that to the
mailing list.
skk: After that I will send a planned agenda. Please let me know
if you have any questions or topics. I will send the agenda
list within the week.
astearns: Bert wanted to ask if the start time is known already.
Florian: I think it depends on the venue, but the proposal was 3pm-
7pm followed by dinner.
astearns: E-mail says 3pm-4pm start and that will depend on where
we end up meeting. I'll add a section to the TPAC page
for industry meet-up questions and skk can reference
that.
Rossen: Since we're talking TPAC logistics, is it a good time to
talk Houdini?
astearns: I wanted to get through the rest of the agenda because I
feel the Houdini conversation could take a while.
<astearns> http://www.w3.org/2015/10/meetup-sapporo.html
astearns: Other reminder is there's a Monday night meet-up. If
you're interested, please sign up.
Rossen: Which?
astearns: W3C developer meet-up at Sapporo convention center.
astearns: You can sign up for just the industry demos or also the
social time afterwards.
astearns: That's all for reminders.
Prefixing Policy in Snapshot
----------------------------
<astearns> https://drafts.csswg.org/css-2015/#responsible
Florian: There was something from Microsoft which was addressed. I
think we're waiting on Apple.
hober: I'm gathering feedback. Overall it looks good and is an
improvement. Two areas of concern, though this isn't final
feedback, both are around the difference between what we do
and the new policy. First, when you ship a feature prefixed
you should simultaneously ship unprefixed, that might
change syntax. But that might be a big deal.
Rossen: Is this a must?
hober: Should.
Florian: You must ship unprefixed, you should ship prefixed.
hober: Yeah. That's something we're still talking about.
Florian: I misspoke. The wording is should for both prefixed and
unprefixed.
* tantek notes the prefix discussion sounds confusing
* tantek and if people are still confused remembering it, it
probably needs rewriting to simplify the prose.
hober: The second is the...let me pull up the draft...
hober: The second bit is in market pressure and defacto standards
[reads]
Spec Text:
If a feature is unstable, yet:
- at least three UAs implement the feature (or a UA has
broken the other rules and shipped for broad use an
unstable or otherwise non-standard feature in a
production release),
- and the implementations have rough interoperability,
- and the CSS Working Group has recorded consensus that
this feature should exist and be released,
implementers may ship that feature unprefixed in broad-
release builds. Rough interoperability is satisfied by a
subjective judgment that even though there may be
differences, the implementations are sufficiently similar
to be used in production websites for a substantial
number of use cases.
hober: The main concern is historically adding support for
unprefixed and removing for prefixed are treated as
separate engineering decisions. One is based on stability
and one is on compatibility.
<tantek> huh? unstable = ship unprefixed?!?
<tantek> wow this is confusing
Florian: To put some feedback on that in case the wording isn't
clear, the intent would be is when you ship something
unstable you ship it unprefixed and preferably ship it
prefixed. The preference is that the authors would use
unprefixed unless there's a bug. That changes the model.
In the majority of cases the prefix would only be used to
work around bugs and when you remove the bugs it would
remove the compat hit.
Rossen: I don't quite agree. The prefixed version in a majority of
cases is to wait for other implementations to catch up and
for specs to mature.
Florian: Today, yes, that is the model. The way this is proposed
for the future there is no reason to use prefixed when
they're released simultaneously unless you're trying to
be implementation specific.
astearns: We're talking about an unstable property-that means it's
implemented in at least 3 UA and there's rough
interoperability and the CSS has consensus it should
exist. That's a different stable.
Florian: You may disagree with what's going on, but I wanted to
clarify what's going on. If it's clear and you disagree
that's a different discussion.
hober: Personally I'm fine with it. It's 'should' which is like
must unless you have a good reason.
smfr: The spec needs a word for unstable but follows the three
interop implementations.
fantasai: It uses it for a spec that is unstable. So the spec is
unstable but we have these things happening. We only
have rough interop. The spec is out of date or
incomplete or there's a ton of open issues, but we have
all these people shipping. There will be problems
because the spec isn't finished. This is like the
transforms and transitions case where stuff was still
changing and people were still implementing and there
were all these issues.
fantasai: We do need to be a bit more clear, but there's this
stage where the spec is moving to stable and there are a
bunch more implementations, but the spec isn't finished
yet and might change.
Florian: We shouldn't use a word that means unstable and matches
all those criteria above. Because if you ship something
that doesn't match the criteria you should still take
this approach.
tantek: A couple of points. I think the first problem is in our
conversation of what means unstable vs interoperable. If
we're using unstable we should use what an author would
consider unstable instead of a spec implementation
definition. If something works across most places authors
will ignore that the WG thinks that it's unstable. I think
that needs to get re-assessed.
tantek: I understand the intention that changing the meaning of
when you ship prefixed vs unprefixed is a good intention,
but transitioning to that model will be so confusing and I
think authors will just say screw it and use both. If the
goal is to try and get out of this problematic situation I
don't think that approach will work.
tantek: I don't have an alternative to suggest.
tantek: So first point, use of unstable needs to be author centric
definition. Second is changing the meaning of prefixed and
unprefixed is good intention but will fail.
Florian: To your second point, I wouldn't be surprised people will
be confused and use both, but I don't think it will cause
problems. If people use both the unprefixed is in the
style sheet so vendors can remove the prefixed. So I
think it will be misused, but I don't think that's
causing problems.
tantek: Not causing problems isn't a high enough bar. If you say
this path will improve the situation that's good.
Florian: I think that when this is misused it isn't going to be a
problem.
tantek: So how about not preventing improvement?
Florian: How does this prevent improvement?
tantek: I'm trying to encourage you to re-word your argument in a
stronger way. It sounds like you are close to
demonstrating that the misuse won't prevent the
improvement and in that case it's reasonable to move
forward.
Florian: I think it won't prevent the improvement where vendors
can remove the prefixed version once the bugs are ironed
out because there will be no risk to compat by removing
the prefix because everyone also used the unprefixed
version
tantek: I think you need to put that into the spec. What if
authors use both? And then put what you said. And that
will demo why impl should use this new policy. I think
that's a strong argument and it should be clear.
tantek: Does that make sense to everyone else?
* fantasai is in favor of clarifying :)
astearns: I think some of the argument is in the section, but it
can be improved. So I'm hearing we need to clarify what
we mean by unstable and clarify why this change in
prefixing policy is a good thing. So we can get that and
circle around.
<bradk> Are authors supposed to list the prefixed versions of
properties last?
ACTION Florian to improve the note explaining why the prefixing
policy change is good
<trackbot> Created ACTION-722
ACTION fantasai fix up the terminology around 'unstable'
<trackbot> Created ACTION-723
tantek: I'd ask leaverou what she thinks unstable means when
authoring.
<bradk> "Unstable" = not ready for general use, features/syntax
might change.
astearns: hober, you're still collecting feedback. Do you know
when you'll be done?
hober: Not offhand.
Rossen: We're still collecting too so I'm sure this won't be the
last time we discuss it. Ideally the changes we're
discussing will come about soon so we don't have to go
back for another few weeks to circle back on this set of
changes. It would be helpful to start stabilizing the
subject.
Florian: Yes. This is a change in terminology and a note. This
isn't changing the actual policy.
Rossen: They are still changes.
Florian: I'll get to it soon.
Writing Mode Issues
-------------------
fantasai: Koji sent a couple in. Let me pull up the DoC.
astearns: The links I sent in the agenda were Koji's.
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Sep/0100.html
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Sep/0101.html
<fantasai> https://drafts.csswg.org/css-writing-modes/issues-cr-2014#issue-47
fantasai: First issue don't need WG input, I think. For some
implementations that need to support old writing modes
values in SVG syntax but not CSS they could map over
using UA style rule. I was going to add an example.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Aug/0061.html
<koji> this one:
https://lists.w3.org/Archives/Member/w3c-css-wg/2015JulSep/0195.html
[member only link]
fantasai: Main one that's open is this one [#48]. Orientation of
an <iframe> which is 300x150.
fantasai: Does that orientation rotate in vertical text or do we
keep it as 300x150? I lean to keep it because the main
use case is plug-ins where they can't adapt. If there's
a reason it should go the other way let me know.
Rossen: I would argue the opposite. You can argue keeping the
<iframe> and images default sizing logical...
Rossen: Images are upright regardless. You're right.
fantasai: We think the kinds of things that would rely on this
default are more likely to be image-like the logic was
lets make it stay upright.
koji: Firefox, Webkit, Blink, and Trident by default do physical.
Rossen: That's what we do. Everyone defaults to keeping the
'default' size of <iframe> physical. So the width is 300
and height is 150.
Florian: Isn't there a security consideration?
Rossen: What would be different than an image with a default size?
Florian: From an <iframe> not being supposed to know what's going
on. Well, maybe not really. Just ignore me, I'm not sure.
fantasai: I think that's kind of it for things we need to ask the
WG for help on. I'm going to go over the DoC and make
sure everything is wrapped up and colorized. If there's
anything you feel needs to be addressed in this draft
that hasn't yet, please let us know. We're trying to go
for CR soon.
astearns: Do you need a resolution?
fantasai: Yeah.
Rossen: It's good to have in the spec that default replaced size
remains physical.
tantek: How about answering the security questionnaire?
<Florian> https://drafts.csswg.org/css-ui/#security-privacy-considerations
<plh> --> https://w3ctag.github.io/security-questionnaire/
Self-Review Questionnaire: Security and Privacy
tantek: I think you must include this section in the spec to go to
CR if you're touching <iframe>. It doesn't take long and
it's a good practice.
Florian: Even if you end up saying everything is safe at least
you've thought about it.
tantek: Yeah, but even if <iframe> is giving a default size it's
possible to leak information. If I can <iframe> youtube
and get a default size and it's different if you're logged
in that's not information I should have. You see what I'm
getting at?
Rossen: I don't. What you'll see from the <iframe> is if it
defaults to 300x150 it will regardless of the writing mode.
We're not changing anything about replaced default sizing.
We're making it less detectable. Replaced sizing remains
physical.
Florian: That we go that way makes it safe.
tantek: And because it's something potentially cross-origin it
makes sense to put the survey answers in.
fantasai: Because the answers are all no I'm not sure how it helps.
tantek: It shows you've gone through and taken the time. There's a
question about cross-origin.
fantasai: But writing mode doesn't do cross-origin.
astearns: I'm not that enthused about boilerplate no to every
question, but I like that we thought about these things
being there. Should we say in an appendix we looked at
this and it was all no.
<fantasai> +1 to astearns
tantek: And maybe add a note about <iframes> being okay because
it's the default size.
astearns: So resolve to put in an appendix and say that we
considered it as one of the reasons we didn't change the
default replaced size.
fantasai: Is there an official link to the questionnaire?
tantek: The one from plh. I'm pinging the TAG every few weeks to
publish a W3C note version on TR, but that hasn't happened
yet.
plh: The TAG is meeting. I can nag them for you.
tantek: Please do.
tantek: Last time I asked plinss was apparently assigned to
publish it.
<bkardell> tantek: didn't you mention this in tag meeting irc
yesterday?
tantek: bkardell, yes.
RESOLVED: Replaced sizing remains physical. Add an appendix about
the consideration of the security and privacy concerns.
astearns: Anything else?
fantasai: I think that's it for now. We should republish CR
perhaps next week.
plh: In terms of publishing you'll need to ping me or Bert.
Definition of White Space
-------------------------
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Aug/0237.html
fantasai: dbaron sent this issue about making sure the definition
of white space is synchronized across specs.
fantasai: CSS 2 spec has two definitions depending on syntactic or
white space that gets collapsed. One include the form
feed character and one doesn't is the main difference.
fantasai: We should align our specs and HTML and go with the list
that includes form feed. It seems to be an error in CSS
spec that form feeds weren't included since every other
spec has it.
fantasai: Certain browsers collapse other characters, but Firefox
doesn't and they're not in any spec, so I think we
should align on the historical.
TabAtkins: I strongly agree. This is to deal with the white space
used in formatting in your source code, so it should
just be the handful HTML defines.
astearns: Objections?
* bradk would love to be able to collapse NBSP
<bradk> NBSP in the HTML is almost always non-semantic
<TabAtkins> bradk: It's usually used for alignment, yeah, not
semantic purpose, but it's definitely not used in
source code.
* Florian is not sure how often people use form feed to format
their source code...
<TabAtkins> Florian: Right, it's not really used, it's just that
matching definitions across specs is useful.
<Florian> TabAtkins: sure
fantasai: This would effect CSS2.1 errata and CSS text.
tantek: Has there been testing on this?
fantasai: dbaron had one in his message. Firefox follows the spec
except the odd inconsistency on collapsible white space.
Other browsers do this and more.
tantek: So other implementations collapse the form feed. We have
interop on that except Firefox?
fantasai: Firefox includes form feed character. The CSS spec
doesn't include that.
tantek: Awesome.
TabAtkins: It doesn't include it in the definition of white space
in this one place.
<tantek> +1
tantek: Sounds good.
RESOLVED: Add the form feed character (U+000C) and make sure all
CSS specs align on the definition of white space.
Implementability of Computed Value Rules for align/justify-self/items
---------------------------------------------------------------------
TabAtkins: I'm generally okay with the changes. I want to review
and discuss with fantasai.
astearns: Feel free to respond on the list.
TabAtkins: Yep. It's in my 'need to deal with soon' folder
astearns Florian, do you want to do your resizing topic next?
Florian: Either that topic or the discussion from the member only
list about using prefixed examples in the spec
Using Prefixed Examples in Specs
--------------------------------
Florian: When doing a live example in a spec showing how a
property would work a sample rendering using some other
way of displaying it is useful. I did it using normal
unprefixed CSS which works for everything except Safari
where I used a prefix for the behavior. Bert and, I
think, fantasai didn't like the prefix use.
Florian: I can do it using a GIF, but is it bad using the prefixed
fallback for one browser?
smfr: Safari and iOS 9 will support that unprefixed.
fantasai: Part of the reason tantek was arguing to allow was it
functions as an inline test in the spec. As an
implementor reading the spec you can see if your
implementation does this correctly and as an author you
can see if your browser does this. But if you add the
prefix that doesn't work.
Florian: I was using it on the ref side, not the test side.
fantasai: In that case, I don't have a strong opinion.
Florian: I can switch to doing it with a GIF. I'm not sure they're
standard, though they work everywhere.
fantasai: I think they're standard even if there isn't a spec.
Florian: If the criteria to allow it is that it has a standard,
GIFs are not.
tantek: This is prefix in the executable code, not the example?
Florian: Yeah.
tantek: Then it absolutely should be allowed.
TabAtkins: I agree.
tantek: We've gotten exceptions for this multiple times, like
CSS 3 UI.
Florian: That was a slightly different battle.
tantek: No, we have prefixed.
plh: I'm trying to understand the motivation.
plh: The goal isn't to say anyone can use CSS prefixes in their
spec, the goal here is for the purpose of having a reference
if we can't find a way that works in all existing browsers
it's okay to use a prefix.
Florian: I have a double example where on one side it shows what
the property would do which doesn't work right now and on
the other side it shows what it will do once implemented
which I can do using existing properties except for one
browser where I needed the prefix to make it work.
* fantasai thinks this case is fine
plh: Okay, thanks for the clarification.
Florian: I think in general this should be fine, but it requires
judgment where if the spec isn't stable but there are
multiple interoperable implementations, but it shouldn't
be used when there isn't wide interoperability. In this
specific case it seemed fine.
astearns: So we should allow this prefix in this example seems to
be the group consensus.
Bert: This is about the W3C site. It's not about how we ought to
show things to people. If we want to show how something
blinks that's fine. This is about what we can show on the TR
page. That's where we have documents that should stay there
forever and there we want things that should be valid and
stable forever. We want to keep the value of the TR page as
high as possible. I'd say find some other means of showing
blinking.
astearns: I don't see the future compat issue. We're not only
using the prefix, we're also using unprefixed version.
plh: I think we jumped that gun when we said if you want to use
properties that aren't in REC in a CSS spec that's okay. So
we jumped that gun in spec. At the time the question of
prefixes wasn't presented to me. Honestly, I'll have to sit
down with Tim and make sure he's comfortable to say go ahead.
Florian: Should I restore the examples and then we try and publish?
plh: You won't be able to until I sit down with Tim, but if you
want to restore the spec go ahead.
Florian: Okay, so I'll restore the spec.
plh: I may have a chance later today to sit down with him. Some
time in the next four hours.
astearns: So we have a clear desire from the WG to allow the
example and we'll wait to hear from plh.
astearns: There's just two minutes left.
fantasai: I have a quick issue: the status of will-change and
variables which were supposed to be published as CR a
while ago. Who has that ball?
TabAtkins: Me.
fantasai: Can you pass it to somebody else at some point?
TabAtkins: Yes.
astearns: We'll talk about resize issue next week. Houdini meeting
at TPAC on maybe Thursday or Friday will continue on the
mailing list.
astearns: That's it for the week.
Received on Thursday, 17 September 2015 11:07:24 UTC