- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 25 May 2016 20:04: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.
=========================================
CSS tables status update
------------------------
- gregwhitworth updated the group on his progress with the tables
spec.
- It's not ready for FPWD, but he's looking for feedback from
anyone interested in reviewing their work.
CSS 4 UI
--------
- Florian will look through UA stylesheets to list explicitly what
user-select:none applies to.
- RESOLVED: appearance: none for checkbox and radio become
non-replaced elements.
- There was a proposed set of principles for 'appearance'
1) it shouldn't change what you can do with it
2) you can't break web compat
3) should not prevent improvements in the UI
4) It might as well be useful so long as it doesn't violate
the other three principles.
- RESOLVED: add :playing and :paused pseudo-classes
Page Media Query
----------------
- RESOLVED: Apply the same logic as @viewport has for @page size
for viewport size.
Generated Content Spec
----------------------
- RESOLVED: Content property applies to all elements, but only
lone <url> values apply to real elements--other
values will be ignored.
- RESOLVED: Add trailing-slash alt-text to content property.
- RESOLVED: Replace <url> with <image>|<url>
- This spec still isn't friendly for accessibility, but would be a
good guinea pig for doing accessibility mapping.
- dauwhe and Rossen will work with the editing task force and
dauwhe will add a note to the spec.
- RESOLVED: Drop <datetime>
- RESOLVED: Drop document-url
- RESOLVED: Publish new WD of Generated Content (possibly FPWD
depending on patent policy needs).
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics
Scribe: zcorpan
CSS tables status update
========================
<gregwhitworth> https://drafts.csswg.org/css-tables-3/
gregwhitworth: In Sydney we asked for the opportunity to work on
the tables spec:
gregwhitworth: we've made good progress.
gregwhitworth: The blink team reached out regarding height
distribution.
gregwhitworth: We handle border painting.
gregwhitworth: html5 says you can have empty tables, we need to
figure out how to lay that out.
<gregwhitworth>
https://github.com/w3c/csswg-test/tree/css-tables/work-in-progress/microsoft/css-tables
gregwhitworth: We were asked for the tests. we've begun putting
them into a branch.
gregwhitworth: As you can tell we have a ton of investigations.
gregwhitworth: We'll continue to port those over into the test area.
gregwhitworth: The goal is what the test represents and you can
match the test against the spec text, should be
straightforward what is tested.
gregwhitworth: Other browsers to review height distribution etc.
gregwhitworth: Things we've ported over from 2.1 that were
previously undefined.
gregwhitworth: If you can review it, we're not at FPWD right yet
but review is welcome.
Florian: Comment on the methodology:
Florian: If browsers do the same you spec that...
Florian: If nobody makes sense and everyone is different, spec
something that does make sense.
Florian: With regard to table topics that relate to fragmentation
Florian: page UAs have considered this more than browsers.
Florian: Please consider such UAs also.
Rossen: There's no fragmentation definition...
fantasai: For tables there is, in css-break
Rossen: The majority is in css fragmentation.
Florian: Table headers and footers, whether they fragment or not,
browsers are not the primary things to look at.
TabAtkins: Let's describe compat right now.
gregwhitworth: I said slot is not defined, it's an issue.
gregwhitworth: We're early on on this, we are not going to tackle
this in this level.
Florian: 2.1 says it's undefined, now you're removing it.
Florian: I'd rather not say print UAs are irrelevant.
gregwhitworth: Hopefully the next time we talk, we can present
issues.
gregwhitworth: We don't need to handle this now. We haven't begun
to investigate it yet.
Rossen: Is that everything you have?
gregwhitworth: One more link.
<gregwhitworth> table issues readme:
https://github.com/w3c/csswg-drafts/tree/master/css-tables-3
gregwhitworth: If you go to the github repo you can see the issues.
gregwhitworth: External people having input and we're working on
addressing that.
Rossen: Thanks Greg.
CSS UI 4
========
Variants of <input> for user-select:none (Issue 22)
---------------------------------------------------
<Florian> https://drafts.csswg.org/css-ui-4/#issue-2e1305f8
Florian: user-select: none should be applies to button...
Florian: Should the spec say anything about that?
Florian: Should it list which elements it applies?
Florian: What do you think?
Florian: Should it say which elements explicitly?
TabAtkins: Yes. it should say what UAs do.
Florian: Is any browser interested in helping with this?
dbaron: I can tell you what we have in our UA stylesheet.
dbaron: Marker, canvas are none,
dbaron: input and textarea have text,
dbaron: select has none,
dbaron: option has none,
dbaron: optgroup has none,
Florian: Can you dump this?
<hober> search for user-select in
http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css
dbaron: Things that look like buttons.
Florian: I can read the UA stylesheets myself but there may be
knowledge about things that are known bugs etc.
tantek: We can dig into the implementations.
Florian: ok, I'll do that.
<dbaron> https://mxr.mozilla.org/mozilla-central/source/layout/style/res/ua.css
<dbaron> https://mxr.mozilla.org/mozilla-central/source/layout/style/res/html.css
<dbaron> https://mxr.mozilla.org/mozilla-central/source/layout/style/res/forms.css
Allowing pseudo-elements on form controls when appearance:none
--------------------------------------------------------------
<Florian> https://lists.w3.org/Archives/Public/www-style/2016Mar/0190.html
Florian: This was a question from TabAtkins
TabAtkins: As I said in the email, safari and chrome allow
pseudo-elements on form inputs.
TabAtkins: It's used on more than our removal threshold allows,
about 20x more.
TabAtkins: There's a handful that are possible to describe.
TabAtkins: We'd like to allow them when appearance is none
TabAtkins: and make that interoperable with other stylesheets.
hober: This is allowing ::before / ::after?
TabAtkins: Yes.
dbaron: Text input?
dholbert: A non-themed box.
dbaron: There's also a complex structure for scrolling.
dbaron: If you type enough such that the text needs scrolling,
does that work with appearance: none ?
TabAtkins: Whatever element you have that is user editable, the
before/after would be children of that.
TabAtkins: It becomes an ordinary box that is user editable.
dbaron: It's -webkit-appearance in chrome?
TabAtkins: Yes.
dbaron: Which type of input? Not text inputs for me.
TabAtkins: checkboxes and radio buttons.
TabAtkins: I thought text inputs as well.
dbaron: I see it on checkboxes, not text inputs.
[room is testing]
<dbaron> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ainput%20%7B%20-webkit-appearance%3A%20none%20%7D%0Ainput%3A%3Abefore%20%7B%20content%3A%20%22hello%22%20%7D%0A%3C%2Fstyle%3E%0A%3Cinput%20type%3D%22text%22%3E%0A%3Chr%3E%0A%3Cinput%20type%3D%22checkbox%22%3E
TabAtkins: Hum.
TabAtkins: Checkbox and radio are the big ones.
dbaron: If the idea is that appearance: none on checkbox and radio
means all styling goes away.
TabAtkins: Still atomic inlines, just empty, 0x0.
bradk: For search? placeholders?
<dbaron> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ainput%20%7B%20-webkit-appearance%3A%20none%3B%20border%3A%20medium%20solid%20green%3B%20display%3Ainline%20%7D%0Ainput%3A%3Abefore%20%7B%20content%3A%20%22hello%5Ca%20world%22%3B%20white-space%3A%20pre%20%7D%0A%3C%2Fstyle%3E%0A%3Cinput%20type%3D%22text%22%3E%0A%3Chr
<dbaron> %3E%0A%3Cinput%20type%3D%22checkbox%22%3E
dbaron: An appearance: none checkbox is display: inline-block.
TabAtkins: Can you implement this? appearance: none and
before/after on checkbox and radio
dbaron: Yeah, basically that appearance:none checkboxes and radios
are no longer replaced elements.
dbaron: Ok with that.
TabAtkins: Happy to explore more, but start with this.
<fantasai> +1
Florian: The generalization is the next topic.
Rossen: Anyone against this resolution?
Rossen: Proposed Resolution: appearance: none for checkbox and
radio become non-replaced elements
RESOLVED: appearance: none for checkbox and radio become
non-replaced elements.
Generalization of previous topic
--------------------------------
Florian: We're going to have this discussion for lots of topics.
Florian: Form controls are full of quirks, need to look at each
one by one.
Florian: Some are easy like checkboxes.
Florian: Some where you can do that but you need to keep some UA
stylesheet.
Florian: For compat reasons some things need to remain, like range
you need the knob.
Florian: We need to do this at some point, but not right now.
fantasai: Who's not interested?
dbaron: The spec needs an editor.
Florian: I'm editor but I don't want to do it alone.
Florian: OK with an co-editor, also OK staying alone as editor if
nobody steps up.
dbaron: The spec needs an editor who does the work, not in a WG
meeting.
Florian: I have a google engineer who can help me, maybe that's
enough.
gregwhitworth: It would be good to have other vendors also.
gregwhitworth: I can't commit editor time but I want to help.
want to make sure it's not just Google defining things on their own
gregwhitworth: Does anyone have an issue with propagating
appearance: none to the controls?
gregwhitworth: There's an endless cycle.
gregwhitworth: This just exists because webkit compat.
Florian: No....
Florian: I have some general principles that google engineers have
agreed with.
Rossen: Seems like more work is necessary before this is actionable.
Florian: This is an appearance property, not a behavior property.
Florian: It shouldn't change what you can do with it.
Florian: The other principle is you can't break web compat.
Florian: It might as well be useful so long as it doesn't violate
the above 2 principles.
fantasai: The other one is also, maintain the ability to improve
the UI.
fantasai: Whatever we do here should not prevent improvements in
the UI, to adapt to new platforms
Florian: Ok I agree with that?
fantasai: We should adopt the principles, sounds great.
Rossen: Anything else?
<tantek> I like things with URLs.
<hober> https://wiki.csswg.org/spec/css4-ui
<fantasai> tantek, here's a URL
http://logs.csswg.org/irc.w3.org/css/2016-05-10/#e683601
<zcorpan> Proposed Resolution: principles for 'appearance' (1) it
shouldn't change what you can do with it (2) you can't
break web compat (3) should not prevent improvements in
the UI (4) ???
<fantasai> (4) It might as well be useful so long as it doesn't
violate the other three principles
<tantek> fantasai, those principles sound vaguely ok, but too
ambiguous to actually +1. Needs a more precise writeup,
e.g. "it shouldn't change what you can do with it" is so
ambiguous as it could be used to justify anything
<fantasai> tantek, it's not a spec, it's guidance for the spec
writers. It's fine as such imho
<tantek> so yeah, I guess as written up on the JS-dependent URL of
http://logs.csswg.org/irc.w3.org/css/2016-05-10/#e683601,
I would -1 as is
<tantek> guidance which can be used to justify anything is useless
and not worth giving
<fantasai> tantek, suggest improvements?
<fantasai> tantek, I have no idea what you're objecting to
<tantek> I did, "Needs a more precise writeup"
<fantasai> tantek, that's not a suggestion for improvement, that's
a complaint
<tantek> fantasai, how about dereference the pronouns in "it
shouldn't change what you can do with it" to more precise
expressions
Potential features for CSS4-UI
------------------------------
hober: :playing and :paused pseudo-elements for media elements
<tantek> per: https://wiki.csswg.org/spec/css4-ui
hober: Last time we got side-tracked and it got hairy.
hober: Does anyone object to :playing/:paused pseudo-classes?
TabAtkins: We existence proofed for a button that morphs on those
two categories so I agree.
Florian: Putting things into the UI spec or selectors spec....
RESOLVED: add :playing and :paused pseudo-classes
Page MQ
=======
Florian: The size property inside @page should relate to MQ in the
same way as viewport.
Florian: I've written an email with use cases.
<fantasai> Florian's proposal:
https://lists.w3.org/Archives/Public/www-style/2016May/0071.html
Florian: The viewport should respond and influence the MQs in the
same way.
TabAtkins: Page size seems like the same thing as viewport.
Rossen: Sounds reasonable.
dbaron: Do we have impls of what @viewport says to do?
Florian: Edge does it.
dauwhe: [asks about bleeds]
Florian: The size that you query.
Rossen: Any objections?
dauwhe: Do the keywords cause problems?
Florian: Don't think so.
<zcorpan> Proposed Resolution: apply the same logic as @viewport
has for @page size for viewport size
* fantasai agrees with that
RESOLVED: Apply the same logic as @viewport has for @page size for
viewport size.
<break type=lunch>
[Return to Round Display discussion - see part 1]
Scribe: ChrisL
Generated Content Spec
======================
Content Property
----------------
<dauwhe> https://drafts.csswg.org/css-content/
dauwhe: It has been less than 13 years since my last confession...
dauwhe: Pending pseudo class,
ChrisL: handwaving,
dauwhe: have solidly reworked this spec and removed all the cruft.
dauwhe: Some migration from GCPM also.
dauwhe: Content property applies to elements as well as pseudos.
(discussion on which browsers do this already)
<gregwhitworth>
https://bugs.chromium.org/p/chromium/issues/detail?id=597466&can=4&colspec=ID
Pri M Stars ReleaseBlock Component Status Owner
Summary OS Modified
<gregwhitworth> https://bugs.chromium.org/p/chromium/issues/detail?id=597466
TabAtkins: If we have exactly one image in the content property it
is replaced.
Florian: Content property on elements in Presto - was removed.
Everything turns into periods because of mistyped
clearfix rules.
dauwhe: Also added a mechanism for alt text for generated content:
at the end of the content value there is a slash and then
the alt text.
fantasai: example of alt text need is three stars for an HR but
don't want that as alt text
Florian: Or use the image() function and have the fallback inside
that?
fantasai: Disadvantage - its more complex, and you don't want alt
text for other image uses. Just for content.
fantasai: Want it to cascade with the content
fantasai: so put togeter the syntax for the alt and the content it
is replacing.
dauwhe: Should be the value of the string by default.
Florian: OK
TabAtkins: Remember when we wanted to replace arbitrary elements
with arbitrary strings ....
TabAtkins: with images is fine.
Florian: Do we need an extra keyword to opt-in?
fantasai: In general, make it work and find a workaround if it
breaks.
TabAtkins: Prefer we don't do it, only as an image replacement.
Replacing arbitrary elements with arbitrary text has no
good use cases.
astearns: Would it make sense to have a replace() function where
this is wanted?
Florian: Shortening for small screens.
ChrisL: As long as the text is coming from an attr like data-
whatevs in the content, so available to AT
ChrisL: not replacing with random stuff from a stylesheet.
TabAtkins: If it is decorative, still don't like it. there is
already replacement with alt if img doesn't load.
Florian: With cross references, may be easier to write the markup,
but you need more functions than this.
fantasai: There is a content keyword to do this.
dbaron: At some point you are reinventing web components in css
syntax.
dbaron: One of the reasons this got abandoned was hixie went to
work on XBL2 instead which eventually became web components.
TabAtkins: No difference between a literal string and an attr
function.
fantasai: You might want to get title of an abbr and replace with
the title. A11y folks want this.
fantasai: Should not need javascript to use this.
fantasai: Alternate ways to express same concept, selection
between them inline. Needed in publishing.
Florian: Non-metaphor substitutions for people confused with
metaphor.
TabAtkins: Don't put text in attr, you need markup for lang etc.
Florian: So only for images, then?
dbaron: What do you use this for?
TabAtkins: It is one way to do an image replacement.
gregwhitworth: I posted the bug earlier
hober: Custom image replacement.
Florian: Prince, Antenna House and pdfreactor all do text
replacement on arbitrary elements.
ChrisL: For a pdf output, the user sees the output only. so
different from the web browser case where the content, not
the output of rendering, is used.
Florian: Maybe vivliostyle too, need to check.
<Florian> I just checked, and Vivliostyle does not apply the
content property to ordinary elements. (neither for
strings or for images)
Florian: It is proven to be web compatible
Florian: and may be web required. Chrome does it.
<dbaron> it's pretty weird
RESOLVED: Content property applies to all elements, only URL
values apply to real elements. other values will be
ignored.
RESOLVED: Add trailing-slash alt-text to content property.
Scribe: fantasai
ChrisL: It's relatively easy to explain, at least.
ChrisL: Certainly there are a11y concerns with replacing the
document content, so it's reasonable.
gregwhitworth: I'd prefer we didn't do this, but if rest of WG
feels it's worth going after, not going to push back
too hard.
astearns: In some ways doing something a little weird in order to
reflect reality, but also have this mechanism by which
some browser shave implemented some things that have not
been specced with prefixes.
astearns: Others are implementing just to be web compatible.
astearns: We could wait to put this in, until such a time that
other browsers find it necessary to implement for web
compat.
gregwhitworth: We could also suggest that said browsers remove it
to be compatible with the spec.
Rossen: Do we have any kind of usage data?
TabAtkins: No.
fantasai: I'm okay with either way, really want to update the rest
of the spec.
fantasai: Can always revisit this.
plinss: Why url() and not image()?
fantasai: In theory, you can insert an mp3 into the speech output.
fantasai: Be cool if you can do image replacement on text, could
do audio replacement on it too.
plinss: Should be an <image>
fantasai: I think it should be <image> or <uri>
RESOLVED: Replace <url> with <image>|<url>
* plinss notes that <image> already includes <url>
* fantasai notes that <image> is implied to be an image
accessibility
-------------
dauwhe: Had some general questions about a11y.
dauwhe: Existing bugs about generated content not being searchable,
selectable, etc.
dauwhe: I think it should be.
dauwhe: Can we just say that in the spec.
Florian: These various things are related.
Florian: Tricky for selectable, because APIs for selection are in
JS/DOM world.
hober: Need to ask editing TF to improve their APIs.
Florian: ...
hober: Let's just ask them to do it.
Florian: Do we ask them to do it, and then do our thing in the
meanwhile?
fantasai: I think we put how we think it should work in the spec,
and then have them figure it out.
dbaron: Shouldn't assume they'll do it.
hober: Hence why I suggest we ask them to do it.
<gregwhitworth> ^^ Is not in Chrome/FF
<gregwhitworth> not sure if it works in webkit or not
<gsnedders> gregwhitworth: I don't think it ever has been
elsewhere. Including (Zombie)Presto.
<gregwhitworth> gsnedders: what?
<gsnedders> gregwhitworth: It's not ever been selectable anywhere
except Edge, not in Chrome/FF/ not even in Presto with
it's general content: support
<gregwhitworth> gsnedders: so what you're saying is we're awesome
<gsnedders> gregwhitworth: yeah, you're the best <3
Rossen: A couple months ago, had a conversation with Richard ???.
Rossen: As well as Michael Cooper.
Rossen: Their request was to create a spec which is similar to the
other accessibility mapping specs, but for CSS.
Rossen: What you're describing would be a perfect fit for that spec.
dauwhe: That was my next question...
dauwhe: Whose responsibility is this?
Rossen: There are two types of things that we do in CSS that make
a11y harder.
Rossen: One is generated content, which adds more visible content,
which is not accessible through the DOM.
Rossen: We also create box structure that is not backed up by
elements
Rossen: e.g. anonymous boxes.
Rossen: Not something that OM can query. Nor AT should care about.
Rossen: Point of that spec was to define all of the different ways
that we are affecting accessibility, and specify what the
UA is supposed to provide so that a11y doesn't suffer.
Rossen: Other one was 'order' property, which we partially address
with prose in the spec.
Rossen: But still on the hook for that.
Rossen: My feedback would be to start focusing on that spec.
Rossen: Maybe point CG to that spec.
fantasai: While I think it's fine to point to that spec for more
details, I think we should be very clear in this spec
that generated content is to be accessible.
Florian: Is visibility of a piece of content in the a11y tree and
select-ability of a piece of content, and search-ability
of a piece of content the same thing, or is it not?
ChrisL: It should not be.
ChrisL: They're not orthogonal, but not completely independent
either.
Rossen: You're describing different views of a document.
Rossen: You're describing views for presentation on screen.
Rossen: And view for an editor.
Rossen: And view for an AT.
Rossen: Editor being selection.
Florian: I disagree that editing and selection are the same.
Rossen: Then your engine is weird.
Florian: If these things are not the same, which are affected by
'user-select: none'?
Florian: If you 'user-select: none' is it searchable? Is it in the
a11y tree? Obviously it's not selectable.
Florian: One suggestion has been, make ::before/::after as
'user-select: none' by default, can be overridden, would
get you current behavior.
fantasai: ..... no, I don't think that's a good idea. That's just
a bug.
<dbaron> I think these are just explaining why generated content
is a bad idea.
dauwhe: Would this be a good guinea pig for starting work on AT
type things?
Rossen: Totally.
Rossen: Sounds like we should start a spec for this, would you
co-edit with me?
dauwhe: Sure.
astearns: So we should go back to the editing task force.
astearns: And then put a note that we want to do that.
fantasai: I think we should just have the spec require it, and
then add more details and better improvements to make it
easier to implement elsewhere.
dbaron: I think generated content is a feature of the Web platform
that doesn't get along with a lot of other features of the
Web platform, and we can try to make a bunch of things
work, but we're going around the way it works.
plinss: But there's lots of uses for GC in publishing.
TabAtkins: Printing doesn't have the same weaknesses as an active
DOM.
plinss: Replacing content has been a thing in word preprocessors
for a long time.
dbaron: But CSS is probably the wrong layer to do it.
dauwhe: Yeah, but this is the world we're in.
dbaron: I'm not happy about expanding it. Also should not have to
tell other group to fix our problems.
fantasai: Well, we can't not fix the problem, or pretend it
doesn't exist.
hober: The Editing TF is where the expertise is for this.
[discussion about accessibility mapping specs]
Florian: UI question, but related,
Florian: Not speaking about search-ability, but select-ability.
Florian: We previously resolved that 'user-select' property
applies to ::before/::after and if it does, it's
defaulted to none.
Florian: Do we go away from that ?
Florian: Edge makes it selectable.
Florian: Or do we discuss this some other day.
dauwhe: Why did the spec say it shouldn't be selectable?
Florian: Because a lot of time it's decorative.
Florian: Should be able to flip it.
Florian: What's the default?
gregwhitworth: There are far more people using it for
non-decorative uses than you think.
fantasai: I would prefer if the spec didn't say "go this
direction" when we actually want to go in a different
direction.
TabAtkins: Then make it an issue in the spec.
datetime() and document-url()
-----------------------------
dauwhe: There's a bunch of old stuff about datetime() and
document-url()
dauwhe: I would have use cases for this, but do we think this
stuff should be in there?
<dauwhe> https://drafts.csswg.org/css-content/#content-datetime
<dauwhe> https://drafts.csswg.org/css-content/#content-document-url
dauwhe: These are really useful things in my world.
dauwhe: Left them in.
dauwhe: Wanted to hear from CSSWG.
dauwhe: Prince does not have these. Don't know AH status.
TabAtkins: Without any real definition, not very useful to have in
the spec :-)
dbaron: I'm going to suggest that they be removed.
TabAtkins: One good reason to remove is to just establish them as
variables.
TabAtkins: Use cases are obvious.
TabAtkins: Show up in footer of everything you print off the Web.
fantasai: You could write a whole book about formatting dates and
times. Think we should drop.
RESOLVED: Drop <datetime>
ekimber: Should be call it document-uri
plinss: No.
ekimber: No?
plinss: No.
TabAtkins: Could also get this from a variable.
RESOLVED: Drop document-url
Publication
-----------
Rossen: Anything else?
fantasai: Can we publish a new WD?
TabAtkins: There's a ton of new stuff here.
fantasai: Was copied over from GCPM, per WG resolution on GCPM
split.
hober: I'm in favor of publish an update to this.
RESOLVED: Publish new WD of Generated Content
dbaron: And do various shortnaming dances.
ChrisL: If not yet published under patent policy, then FPWD from
patent policy
Florian: Some parts were published under GCPM FPWD.
[basically, deferring FPWD/WD distinction to staff contacts]
<br>
Received on Thursday, 26 May 2016 00:05:23 UTC