- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 31 Jul 2019 19:44:36 -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.
=========================================
Charter Update
--------------
- Work is being done on the new charter. The document is available
here: https://w3c.github.io/charter-drafts/css-2019.html and
issues are being created in the charter github here:
https://github.com/w3c/charter-drafts/issues
CSS Images
----------
- RESOLVED: Accept proposal with an added note current solution is
experimental and may change (Issue #3799: Consider
changing initial value of 'image-orientation' to
from-image)
- The proposed text for issue #1984 (Specify fallback behavior when
replaced or background image content not available) will be
edited to specifically call out the interstitial state between
image swaps. Myles will have his team review the text and then
the group will try and resolve on the next call.
- RESOLVED: Treat fragment only URLs as only elements, never images
(Issue #383: Ambiguities in handling url())
- RESOLVED: Change requirements from 'should' to 'must' (Issue #383)
- RESOLVED: Add the edits in
https://drafts.csswg.org/css-images-3/#ambiguous-urls
(Issue #383)
- After the group resolves on issue #1984 there will be a call to
republish CSS Images
Can we start ignoring CSSRule.type?
-----------------------------------
- RESOLVED: Don't invent new .type values for future rules;
recommend usage of .constructor.name (Issue #4142: Can
we start ignoring CSSRule.type?)
CSS Overflow
------------
- RESOLVED: Align scrolling behavior of visibility:hidden with
visible descendants for overflow:scroll to behave the
same as overflow:hidden (Issue #4113: Should a
visibility:hidden overflow:scroll be scrollable?)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jul/0031.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Benjamin De Cock
Elika Etemad
Simon Fraser
Dael Jackson
Brian Kardell
Peter Linss
Myles Maxfield
Nigel Megitt
Thierry Michel
François Remy
Melanie Richards
Alan Stearns
Regrets:
Dave Cramer
Chris Harrelson
Florian Rivoal
Jen Simmons
Fuqiao Xue
Scribe: dael
Charter Update
==============
Rossen: Fuqiao sent regrets. He's the contact in charge of the
process from TPAC. I was hoping for an update.
<astearns> the draft is here:
https://w3c.github.io/charter-drafts/css-2019.html
Rossen: He's planning to make timelines in charter itself, though
admitting most likely will be inaccurate and will need WG
discussion to correct
Rossen: There is a thread on the private ML. If you want to
participate and help please do so
Rossen: If nothing else we can move on.
<fantasai> I agree with Florian's comments in
https://github.com/w3c/charter-drafts/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+%22%5Bcsswg%5D%22
tantek: Is there a reason to keep on private list vs using GH issues?
astearns: We are using GH issues on the charter and it's appropriate
to open more
Rossen: Discussion is on private because it's a fork from my call
for agenda items
tantek: Good to know public GH is an option. I would encourage
people to use that instead of private list unless there's a
specific reason to use it
fantasai: I think that's a good point. I don't think it belongs in
our WG. There is a repo for comments on charters.
tantek: Public?
fantasai: Don't know
AmeliaBR: Yes it's public. florian posted link on IRC
Rossen: Go ahead and post issues and let's move charter forward
CSS Images
==========
Consider changing initial value of 'image-orientation' to from-image
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3799
TabAtkins: Some time ago when wrote image-orientation we set initial
value to none. People requested initial to be from-image
so it can auto rotate based on what camera captured. Some
safari versions do and some don't. smfr wants apple stuff
consistent
TabAtkins: We did use counter and found numbers reasonable. Lots of
images have default EXIF value.
TabAtkins: Less then a millionth have orientation data so will be
changed. We don't know how many will change for the
better and which for the worse. From personal experience
I suspect a lot will be fixed. I see a lot incorrect on
the web.
TabAtkins: Given tiny percentage of poss breakage we recommend init
value is from-image
<tantek> wow I'm guessing lots of bad invisible EXIF data that's
been neglected to date is going to start screwing up images
<tantek> is there a way to query any web image search service for
the EXIF properties (or even existence thereof) ?
plinss: A little concerning to me. I wrote code that does EXIF
determination. How do you make that work in fallback if
browser won't do that.
TabAtkins: If you have control over image correct is rotate and fix
EXIF or remove the EXIF and do the transform on browser
side. Either works consistently regardless of browser
initial value
dbaron: It seems like it would be good if you make change to spec
you should note it's experimental and might change back if
there's compat problems.
TabAtkins: Yep
smfr: iOS has been this way for many years. I think...there will be
compat problems but benefits outweigh. Most common images with
EXIF orientation are those from mobile devices. This benefits
those images most which is common.
plinss: Agree it's desired. Just concerned on compat and make sure
websites can manage if they need to.
<tantek> +1 to dbaron's suggestion, and what plinss said
smfr: Can with image-orientation css property
plinss: Yeah, worst case can change behavior
dbaron: Is iOS detectable by looking at computed value of image
orientation?
smfr: I don't think we support image orientation yet. Just respect
EXIF. Want to both everywhere at the same time. On iOS I don't
think it's detectable by web content if image rotated through
EXIF data
plinss: I don't remember details. I remember a lot of work to make
it cross browser. Don't object right now. I'll look at what
I did and see if it's problematic and if it is I'll bring
it up.
Rossen: Sounds like leaning toward accepting proposal with an added
note current solution is experimental and may change
<tantek> no objections, but expecting breakage
RESOLVED: Accept proposal with an added note current solution is
experimental and may change
Specify fallback behavior when replaced or background image content
not available
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1984
<fantasai> Changeset
https://github.com/w3c/csswg-drafts/commit/846d21d922fa4a47abea7be3ab57bcf3ebf62395
TabAtkins: Request for review because change to CR Images 3. Chris
pointed out invalid counts things not finished loading
the same as fails. Doing fallback based on invalid images
would treat them the same and this doesn't seem
desirable. Shouldn't fallback to a second image if the
image hasn't finished loading.
TabAtkins: Separated the concepts and you're allowed to be smarter
in certain specific ways. Image function will be
different on how we do fallback
TabAtkins: Making sure this is okay and wording looks good
AmeliaBR: Loading image state that includes images that are lazy
load that hasn't started loading?
TabAtkins: Yeah
Rossen: Anything else besides a call to action?
TabAtkins: We'll need resolution. We can ask next week if want time
to review. Else can resolve now
Rossen: Do people feel this is trivial enough to resolve?
myles: We did a bunch on asynchronous image decoding last year. In
cases when script involved it changed css and html attributes
dynamically. As script changes from one image to another the
interstitial state mattered. This is tricky to get right. I
should take this to our team and make sure it matches our
research
TabAtkins: Okay.
AmeliaBR: Good point. Might need explicit call out. An image that
previously loaded an image but is now loading new data
TabAtkins: You're right. We should call that out. We should call out
an image being replaced as a sub category of loading
image.
smfr: I would like clarification on the loading case; it says may
trigger fallback rendering in contexts that offer it. Is it a
may in UA may and what are the contexts?
TabAtkins: Accidental may. Contexts are none right now. Image
function will once it's defined.
fantasai: It isn't. While an image is loading you may trigger
fallback but you don't have to. You may want a loading
image icon. Because not broken we wanted to let UA decide
correct thing, fallback or loading indication. That's why
next sentence is must
fantasai: We made a distinction there. One is required, one optional
TabAtkins: Makes sense
<tantek> wait am I missing something? I thought some browsers
rendered the alt text before an image was downloaded
<tantek> and thought that was specified in the HTML spec
<fantasai> that's a fallback rendering, technically :)
<tantek> agreed
<tantek> however the issue didn't mention alt text so I'm confused
<fantasai> it says "fallback rendering"
<fantasai> Because what the fallback is varies, not all images are
replaced elements
<fantasai> some of them are in 'content' or 'list-style' or
'background-image'
TabAtkins: I think we should take myles's edits and then bring back
to list. Let myles review and try and resolve next week
Rossen: Next week we'll review again. Next week is APAC time, a
reminder.
Ambiguities in handling url()
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/383
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/383#issuecomment-513416574
TabAtkins: This comment has the questions ^
TabAtkins: This is handling the cases where like in mask-image a
url() might be an element in a doc or a doc as an image.
Defined ambiguous image URL that can be used in this
situation.
TabAtkins: Defined from the discussion where conclusion was load
both ways. Check for an element to be reference and if
there isn't load it as an image
TabAtkins: Want to request review of text as written.
TabAtkins: Specific questions: resolution didn't call out
fragment-only url()s. Loading those as an image is just
the same document. I suspect they should always be
element references.
TabAtkins: We resolved with should rather then must. I wrote as a
must because didn't seem to have a good reason to
diverge. Wanted to confirm if it is a should or a must.
TabAtkins: Fragment only URL. Does it make sense for it to ever try
and load as an image? Else will spec they're reference
only.
nigel: Strange use case, TTML. Images can be referenced by fragment
URL. I'm not convinced this is same use case. Words sound
similar.
TabAtkins: Same use case. But talking about an SVG pointing to
itself with a fragment. Not pointing to something else.
nigel: Is the same where fragment pointing to defines contents of
image to display
fremy: But then you're pointing to element in same document with an
ID. But not loading entire document
<tantek> right it's an IDREF
TabAtkins: If pointing to a thing inside it's an element reference.
Not loading whole file again to render as image.
AmeliaBR: In that case it is being used as an element reference. The
only case where you have a hash reference and doing weird
things with SVG views. I have in SVG an example where I
call out that if you use a hash only URL in a property
that only expects full files you will get correct doc as a
full image file
TabAtkins: Fine because not ambiguous URL
AmeliaBR: That's not an ambiguous situation nor a realistic use case
for ambiguous references
TabAtkins: That's something that takes an image not an image or
reference. That's cool and not relevant here
fantasai: I think nigel's case needs to called out more carefully.
You are pulling out a reference to an element, but for
mask image a reference is pointing to an element. nigel
case you're pulling out the element but then using as an
image type, not a mask-element type. Treated as an image.
Element reference we're pulling out of document.
<tantek> what if the element is a picture element or has multiple
srcs etc
TabAtkins: Seems fine. It's reasonable to have element reference for
an image denoted by elements pointing to. This is
different then loading whole file as an image
fantasai: For mask-image an image type you treat as an image and use
alpha to turn into mask. mask-element is an element.
referring to an image you can't use as a mask-element
TabAtkins: Right. mask-element...mask-image defines it must be a
mask. nigel's use case in TTML would define the reference
element can be whatever image defining element is. Use
cases define what's a valid reference element. here's no
ambiguity there
AmeliaBR: What talking about now is if element you reference is not
valid in property making reference what do you do. Always
relative to context of the reference as to if the element
is valid
nigel: If the URL used to point to image but sub-resource in
document isn't defining an image. In that case what should
you display. Is that it?
<tantek> or what if the subresource it points to defines *multiple*
images?
TabAtkins: Yes and the text is you just load the whole document as
an image. Hopefully it's a SVG and it works. If not you
wrote bad CSS.
nigel: Will you go around circles forever doing that?
TabAtkins: Not sure what's circular
nigel: What I heard was try and load it, try and go there, find it's
not right, try again
TabAtkins: Try and load as a document, look and see it's type
expected, then go back and load the whole thing as an
image. Different state that does not trigger same
rendering. And this is why fragment only which refers to
same document we think should not try and fallback
because that produces the circularity
nigel: Okay, I'm with you
<fantasai> I still think it's wrong. Nigel's case is "in TTML, you
can refer to an <image> using a fragment URL to an
element in the TTML document"
<fantasai> If you wanted to use such an image as a mask-image
<fantasai> You can't.
<fantasai> Because we try to load it as a <mask> element, and it
fails.
smfr: I don't like the double load. Can we resolve this with a new
function like URL but lets author state what they'd like.
fantasai: Have image() for that but no one implemented
TabAtkins: We did have that, but this is the resolution we came up
with instead. Works fine with FF. Don't know with the
rest of stuff.
Rossen: You're fine with resolution?
TabAtkins: I am, yeah
<AmeliaBR> Re TTML maybe wanting to use image references in mask: if
there is demand for that, we can always add that to
mask-image as a valid type of element reference.
<AmeliaBR> The edited text:
https://drafts.csswg.org/css-images-3/#ambiguous-urls
<nigel> AmeliaBR sorry that's a misunderstanding - TTML does not use
image references in mask. It doesn't do mask at all.
Rossen: Any other comments? Or try to resolve
Rossen: Objections to the proposed resolution?
Rossen: What's the actual resolution text?
TabAtkins: Does the text added look fine? Should match previous
resolution
Rossen: Do the others hinge on this? If people need to review edits
might have to move on.
fantasai: I don't know if the sub issues need extra time. Can
resolve on those and then edit main text
Rossen: Let's do sub issues
TabAtkins: On the assumption that this text is good, do we want to
treat fragment only URLs as only elements, never images
Rossen: Objections?
RESOLVED: Treat fragment only URLs as only elements, never images
fantasai: Resolved on using should, do we change that to a must? Not
sure what you would do if disagree with the should
Rossen: Objections to change from should to must?
RESOLVED: Change requirements from 'should' to 'must'
Rossen: Are those the sub issues?
TabAtkins: That's it
Rossen: Back to main one. Do people need more time? Fine if you do.
Otherwise we can resolve
AmeliaBR: I looked through comments. Once case that doesn't disagree
but maybe needs callout in spec. When you do have a same
file hash only URL we're not causing any reload or
fallback but there is a chance the hash might be invalid
to start and valid later because DOM is mutated and an ID
appears
TabAtkins: That would be general css is stateless and things reflect
current truth
AmeliaBR: Okay. Consistent with rest of resolution and no special
fallbacks in that case
Rossen: Great.
Rossen: Do people need more time to review? Otherwise I'll call to
resolve.
Rossen: Objection to adding the edits in
https://drafts.csswg.org/css-images-3/#ambiguous-urls ?
RESOLVED: Add the edits in
https://drafts.csswg.org/css-images-3/#ambiguous-urls
Image publication
-----------------
fantasai: Happy to do it as soon as make edits. We're waiting on
myles for the one issue
Rossen: We did push on to next week. We can ideally have edits for
next week and resolve to republish.
Can we start ignoring CSSRule.type?
===================================
github: https://github.com/w3c/csswg-drafts/issues/4142
TabAtkins: Was defining @property rule. I remembered we have to
register .type on the wiki page. It's a terrible pattern
from the 90s. We just do strings now. Does anyone find it
valuable to make the change? We deprecate .type and all
new CSS rules us a placeholder value. Add a new property
that exposes name of rule as a string
<fremy> +1
<dbaron> sounds like a good plan
<fantasai> maybe .typeName?
TabAtkins: That's how other things work. SVG now works like this.
It's easier to work with.
TabAtkins: Objections? Anyone feel it's worthwhile to do or not and
we live with current system?
emilio: Usually when I do CSSOM stuff I do instance of rather then
checking .type. Is new property really necessary?
<AmeliaBR> .constructor.name works
fremy: If you go across iFrames it doesn't work. Have to get
constructor constrained to a string
TabAtkins: True
TabAtkins: Mostly this is just terrible smell and have to keep doing
it for new rule types. Would like to stop. If we're okay
with instance of and iFrames are awkward. I'm okay with
just saying we stop using .type and future rules get a
placeholder
<astearns> +1 to stop using .type
emilio: No strong opinion. I'm happy with string API. fremy point is
nice
fantasai: No objections to adding, but do we want everything else to
have same type or maintain pattern going forward and
encourage string
TabAtkins: Biggest encouragement is make int not work
AmeliaBR: Do we have use counter on how often .type are being
accessed?
TabAtkins: No. Pretty certain it's non-0. Removing .type isn't
needed, just leave as is as a fossil
AmeliaBR: I support doing what we did with SVG where new things get
unknown enum and you have to figure it out with some other
way. Knowing how much current enums are used we'd know how
many people would lose going forward.
TabAtkins: They can switch for new values
myles: Can't you use object.constructor.name and get a string?
fremy: True. But then you need class for each thing you create
TabAtkins: We don't right now. Weird thing HTML does. We use a fresh
class for new rules
fremy: Reasonable to me. That works for everybody. Create unknown
and stop increment the counter
myles: Right now all css rules have own subclasses. Would work.
TabAtkins: Okay with that. Works across iFrames. Would let us drop
to tombstone .type and not use in the future
TabAtkins: Let's ask for resolution on that
Rossen: Objections?
* fantasai is a little uneasy with making .type return the same
value for all future rules, but not gonna object
RESOLVED: Do not use .type in the future specifications
myles: Should resolution say use?
TabAtkins: I'll clarify in the issue
fantasai: Let's retype the resolution TabAtkins
RESOLVED: Don't invent new .type values for future rules; recommend
usage of .constructor.name
AmeliaBR: Do we want to get more specific and say that any rule type
that doesn't yet have a declared type value should return
0 which is the unknown rule from DOM2?
AmeliaBR: And with that are there any specs that declare a value and
haven't been impl? Should they be included?
TabAtkins: The only recent one is feature values. I'm fine with it
staying how it is. I don't think any new @rules other
then @property
fantasai: Might be in future
TabAtkins: Yeah, but this ask was about new @rules in specs that
could be changes to match resolution
TabAtkins: We'll find them
CSSOM View
==========
{element,elements,nodes}FromPoint but without restricting to the
viewport clip?
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4122
TabAtkins: Still active discussion on list. Prefer to defer
emilio: sgtm
CSS Overflow
============
Should a visibility:hidden overflow:scroll be scrollable?
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4113
smfr: You have overflow:scroll with visibility:hidden but a visible
descendant. Should you be able to scroll if you interact? If
programmatic movement should it move things around?
Rossen: Current behavior?
smfr: Cannot interactively scroll, but can through programmatic and
things happening on descendants. I think that's reasonable
<Rossen> https://codepen.io/anon/pen/NZZvgY
Rossen: Is ^ the example?
smfr: Yes, I think so
emilio: FF behavior is same but we allow scrolling interactively the
first time which is weird. Would think of it as a bug.
<smfr> https://codepen.io/smfr/pen/orRLqN
smfr: Simpler example ^
[everyone looks at the examples in silence]
Rossen: Your definition, if I'm getting it correctly, for purposes
of computing scroll bounds for scroller with
visibility:hidden descendants are not counted as part of
scroll bounds for this scroller?
smfr: Not about scroll bounds. element.scrollHeight is same wither
or not overflow:Scroll is hidden. It's about if UA allows
interaction
TabAtkins: final codepen has a scrollbar, but you can't scroll it
directly
TabAtkins: If you were to make it scroll bounds it means can't be
scrolled by anything. Programmatic and bubbling still
works
smfr: Behaves similar to if it's overflow:hidden. Maybe can write in
same way as overflow:hidden which allows programmatic scrolling
Rossen: Reasonable. Aligning with overflow:hidden would be similar
behavior to something people know how to use. People know
you can select and drag to scroll overflow:hidden scrollers.
Rossen: Other opinions?
Rossen: Proposal: Align behavior of visibility:hidden with visible
descendants for overflow:scroll to behave the same as
overflow:hidden
smfr: Also question on if pointer-events:none.
Rossen: Separate issue?
smfr: No. Don't know if need separate or lump in.
<dbaron> seems like pointer-events:none shouldn't effect
keyboard-based scrolling?
Rossen: Since we're a minute past let's resolve on this. If want to
try and lump in lets do that later.
Rossen: Obj to Align behavior of visibility:hidden with visible
descendants for overflow:scroll to behave the same as
overflow:hidden
RESOLVED: Align scrolling behavior of visibility:hidden with visible
descendants for overflow:scroll to behave the same as
overflow:hidden
<dbaron> I assume this means for scrolling behavior and not for
layout (e.g., size of scrollbars)
Rossen: We're are hour. If you want to discuss pointer-events let's
do that next week or in github
<dbaron> (was trying to say that but it seemed like my audio didn't
get through)
<Rossen> ack dbaron - yes, I was specific in my initial definition
of the resolution that this behavior is in reference of
scrolling only, thus, I wouldn't expect any changes to
layout, invalidation and/or paint apply
Rossen: Please add yourself for TPAC wiki. We'll chat next week at
APAC time. Have a great rest of the week.
<tantek> add yourselves: https://wiki.csswg.org/planning/tpac-2019
Received on Wednesday, 31 July 2019 23:45:54 UTC