- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 16 Aug 2020 07:54:27 -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 UI
------
- RESOLVED: Limit 'appearance: button' to buttons once we figure out
what buttons are (Issue #5174: Change appearance: button
to apply only to buttons)
- RESOLVED: outline-width may be ignored if outline-style is auto
(Issue #4925: outline-width vs outline-style: auto)
- RESOLVED: Add SHOULD requirement to spec about making sure caret
is visible (Issue #4784: Add caret-width or add spec
that browser maintains caret width despite transforms)
CSS Pseudo Elements 4
---------------------
- RESOLVED: Megan (GameMaker) replaces Tess (hober) as editor of
Highlight API spec
- There was interest in exposing a pseudo for when something has
been searched within the page (Issue #5233: Highlight
pseudo-element for find-in-page / scroll-to-text).
- It could also solve use cases around framention and those
should be considered as part of discussion.
- This is exposing new information so privacy will need to be
considered when writing the spec definition.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#thursday
Scribe: fantasai
CSS UI
======
Change appearance: button to apply only to buttons
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5174
florian: General principle that 'auto' does magic by tag, and 'none'
turns off magic
florian: But we have some legacy stuff
florian: As specified, appearance: button makes things look like
buttons
florian: even when not actually buttons
florian: We could reduce magic of button by only applying
'appearance: button' to buttons
florian: Mozilla was a bit skeptical
fantasai: I think this is one of the things that may be useful to do
on things that are not buttons, e.g. links
fantasai: In a lot of cases they're styled to look like buttons,
and if using native-looking buttons, that would require
this feature to work on links.
fantasai: I don't see a huge benefit from restricting this, given
that <button> can already contain arbitrary content.
If we need to make it work for such a broad range of
content already, I'd lean towards not restricting it.
florian: The current definition would allow you to turn stuff into
buttons, but also weird cases where they should not
florian: but do we reduce this to only compat necessity or do we let
people make things into buttons when possible?
<tantek> not sure about the compat details, however I'm in favor of
less magic here
iank: I think part of the work with the simplifying making
appearance sane was to limit the magic in scope
iank: It seems like a bit of a reversal if we say, actually, we do
want these to apply to everything
iank: so prefer to restrict this down as much as possible
emilio: If compat allows it, prefer to put less magic here
emilio: We have unprefixed appearance, heycam implemented it, and
hacky internal property to support 'appearance: button'
fantasai: Wanted clarification...
fantasai: Are links explicitly called out? can they be used as
button?
florian: Current spec allows any element to look like a button
florian: Chrome says not many people use it, not even on links
emilio: To be clear, magic of 'appearance: button' applies to
everything except input, textarea and non-listbox selects
iank: I believe we've already shipped this in 80 which is quite a
few releases ago
florian: By this you mean the simplification you proposed?
Rossen: That means you're not breaking anyone who depends on this?
iank: Got a few minor reports
iank: No large-scale breakage
Rossen: Based on data, we can live with scoping 'appearance: button'
to buttons only, is this something we can resolve on?
Rossen: Proposed resolution is scope 'appearance: button' to buttons
only
* fantasai is uncomfortable with not applying to links
Rossen: Hearing no objections. Call it resolved. If there's issue
wrt links, I'm sure we can re-open
smfr: Are we saying that 'appearance: button' only applies to the
BUTTON element?
hober: <input type=button> ?
smfr: file input button?
florian: I guess it's BUTTON and <INPUT type=button>
<tantek> and reset
smfr: <input type=submit> ?
florian: Chrome folks can you clarify?
<tantek> Blink folks, what was implemented? <button> <input
type=button|submit|reset>?
RESOLVED: Limit 'appearance: button' to buttons once we figure out
what buttons are
outline-width vs outline-style: auto
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4925
florian: outline-style: auto is what you do when you want to opt
into native-style outlines
florian: some UAs may do a solid outline, but try to do native
florian: UA might ignore the outline-color in that case
florian: but doesn't say you can ignore outline-width
florian: Maybe we should allow UA to also ignore outline-width in
that case
smfr: In webkit we definitely support this, don't want outline-width
affecting native appearance
[+1 from fantasai]
florian: AmeliaBR thought the native outline looked bad and wanted
to say outline-width to make it thicker
florian: so alternative would be if you can't affect the
outline-width on a native outline, the existence of
outline-width causes a non-native outline
florian: Personally I think if you want to style it, then don't use
a native
florian: If it's native, every other property is a hint, might
influence rendering but not necessarily
Rossen: Magic of having something like outline-width switching out
of native one is really magic to me
Rossen: This sounds like a broken feature
Rossen: so either require to apply, or make optional, but don't
switch out
florian: Proposed resolution, just like outline-color, outline-width
may be ignored when outline-style is auto
<tantek> +1
RESOLVED: outline-width may be ignored if outline-style is auto
CSS Pseudo Elements 4
=====================
Highlight pseudo-element for find-in-page / scroll-to-text
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5233
florian: In Pseudos 4 we have ::selection, ::grammar-error,
::spelling-error
florian: Another thing people sometimes want to style is
find-in-page highlight
florian: so maybe we want one of those
florian: I think I'd like to point out two things
florian: There is a work in progress spec to try to make it possible
for authors to create custom highlights for any reason
<Rossen> spec in reference is https://drafts.csswg.org/css-highlight-api-1/
florian: On the JS side of things, you'd set ranges on the page
florian: On CSS side you can style them
florian: If you want to style the browser find-in-page
florian: pointed out at least by Apple
florian: unlike the others, the UI that is used by some browsers
florian: isn't something you can create in CSS
florian: so expressing through selector, you can't express those
effects in CSS
<tantek> curious about the visual effects that can't be expressed in
CSS, screenshots?
florian: So proposed resolution is partially no change, and
partially poke the editors of that spec
cbiesinger: scroll-to-text is that when searching for a thing and
click search result, the browser will scroll to the
first matching fragment
florian: idk if we want authors to have control over the UI
florian: or if want consistency across pages and should stay out of
authors' hands
<tantek> this is also used by the IndieWeb for annotations and
marginalia with fragmention https://indieweb.org/fragmention
tantek: 2 questions
tantek: find-in-page seems like a well-established feature
tantek: Effects might not be consistent across browsers, could study
and figure out what the effects are
tantek: Curious about effects that can't be expressed in CSS
tantek: maybe add screenshots of the effect to the issue?
tantek: Happy to defer decision until we have more info
tantek: Don't seem to have a rush
tantek: On scroll-to-text or marginalia use case
tantek: in the Indie Web community, there's a diversity of how
authors want to style this effect
tantek: both from perspective of person linking, and from
perspective of site linking to the text
tantek: Sometimes author wants to say "these are the words I want to
select"
tantek: and leave up to destination to highlight / style or not
tantek: Third case of browser doing something by default if neither
author of link or author of page wants to do something
tantek: so complex interaction between author of the link, author of
the page
tantek: Maybe want to decide text fragment, or whole paragraph, or
section, or something
tantek: and maybe browser does something
tantek: Maybe need to investigate more
tantek: I see the utility for a page to control the presentation of
highlights and annotations
tantek: but requires more study of possible effects to come up with
a good solution
tantek: Also sometimes animated
tantek: fragmention to a blog post of mine, my site will scroll to
that paragraph, not to the text itself
tantek: and then do yellow highlight on that paragraph which then
fades away
tantek: non-intrusive, here's what you are looking for
tantek: didn't want to pollute styling with something persistent
tantek: not sure that's possible with pseudo-element either
tantek: Bunch of ways people doing presentation effects with this
tantek: so requires further documentation before designing a solution
<tantek> example link to the animation effect I was mentioning:
https://tantek.com/2020/187/b1/changes-indieweb-organizing-indiewebcamp-west#keep%20listening
(should work in any browser with JS turned on, Fragmentions
implemented with a polyfill on my site)
smfr: I don't think the page can currently detect when the user does
find in page
smfr: If we allow highlighting, then that exposes that information
smfr: so some privacy concerns there
smfr: not sure I want that to happen
fantasai: I don't think anything is exposed to the author
fantasai: Highlight pseudos don't affect computed style or layout or
anything except painting for the user
smfr: Is there an API to detect?
<tantek> yes that's what I remember
florian: not yet determined
smfr: user after finding, can hit ? to select the result
florian: Back to tantek's point wrt research
florian: One aspect not doable in CSS in general
florian: these pseudos are non-tree-abiding, and cannot affect layout
florian: so things that you can do in CSS in general, you can't do
with these types of pseudo-elements
florian: so need to know what authors would want to do, if it's even
possible
chrishtr: [asks for tantek to clarify]
tantek: IndieWeb community is trying out different presentations of
how to show fragmention when someone links to your site with
a fragmention
tantek: yellow paragraph highlight + fade is just one example
tantek: others folks have used other effects
tantek: Experimentation is happening on personal websites
tantek: e.g. "scroll that into view, show specific effect"
tantek: using polyfill right now
chrishtr: So writing JS code that parses the text in the URL?
tantek: I believe it's a fairly straightforward simple polyfill
tantek: which then adds class names that you can style
tantek: So that there's a separation between polyfill and provides a
hook that author can style accordingly
tantek: Not everyone has to write JS
chrishtr: Main response to that is cool to be experimenting with
this effect
chrishtr: ...
tantek: There are other interactions where select text in a blog post
tantek: You'd have options to then tweet that text, or do something
else
tantek: multiple phases
tantek: method of causing a highlight to occur
tantek: DOM hooks to style the highlight
tantek: Independent of that you could potentially provide a UI to do
something with the highlighted text
tantek: e.g. +1 the highlight, or copy and post to Twitter
Rossen: sorry to interject, but I think we're straying
chrishtr: I agree with those use cases and would like to follow up
offline
<tantek> looks like the fragmention polyfill I'm using puts a
"fragmention" attribute on the containing paragraph (or
possibly nearest block-level element)
chrishtr: Main point is, as long as we're making progress towards
exploring this space so we can find the right APIs to
expose that's good
chrishtr: Right now feature in one browsers that does not allow
customization of the color
chrishtr: and quite a lot of dev requests to change color in that
particular UI mode
chrishtr: and want to respect that desire and make progress to
authors customize look and feel
florian: The challenge here is that these are very restrictive
pseudo-elements, only a few aspects of rendering can be
change
florian: so need to see if what is desired is possible to solve via
highlight pseudo
Rossen: Somewhat related to highlight API spec
<tantek> color (and background-color) are just the beginning of
these needs, that's the point
<tantek> we shouldn't be prematurely optimizing for only color is my
point
* fantasai thinks that find-in-page vs fragmention are slightly
different in their needs
<tantek> fantasai I agree and you should say that on the record :)
hober: I'd like to step down as co-editor of highlight API, haven't
had time
hober: I'd like to suggest as my replacement Megan Gardner
hober: She did the WebKit implementation
florian: I don't plan to step down, and I look forward to work with
Megan
RESOLVED: Megan replaces Tess as editor of Highlight API spec
fantasai: think that find-in-page vs fragmention are distinct
features with slightly different needs
<tantek> +1 fantasai totally agreed the features are different
fantasai: so let's keep those things distinct in the discussion
Rossen: +1
Rossen: People working on this need to figure out the boundaries
between host or browser layer and the content layer
Rossen: which exposes user interaction
Rossen: if we are exposing something new, we are adding additional
privacy-related exposure to the content layer
Rossen: That is biggest sticking point, are we starting to expose
something additional, and if so how so
Rossen: outside of that, good thing to continue investigating
<br duration=23min>
CSS UI
======
caret width vs transforms
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/4784
florian: Have an issue with person reporting trouble with carets
florian: particularly when element containing caret is transformed
florian: sometimes caret becomes invisible because < 1px
florian: Proposes a caret-width property that lets you make the
caret big when it would be small so you can still see it
florian: I'm not convinced this is the answer to the problem, but
the problem is real
florian: imho the caret is browser UI, and browser should just make
sure it's visible
florian: shouldn't need someone to tell you how many pixels that is
florian: We already have an unimplemented caret-shape property which
switches between various carets
florian: There's room to say in this definition that the browser
should make it thick enough to be visible
florian: and then we can write tests for that
florian: but maybe there's some other use case for caret-width
astearns: I'll take the silence as lack of appetite for caret-width
astearns: so proposal is to add caret SHOULD be visible through
transforms etc.
florian: Could even be a MUST
florian: Would not say how, but make it visible anyway
florian: Reasonable to say if there's a caret need to be able to see
it
astearns: But we do tend not to get into browser UI territory
TabAtkins: Also some extreme cases, like transforming entire
textarea into 1px, not sensible to see the caret
gregwhitworth: Would like to see bugs filed
gregwhitworth: agree with should
fantasai: If the text is visible, then the caret inserted into the
text should also be visible
florian: Could go three ways. 0) reject to do anything 1) add should
about visibility 2) add caret-width
RESOLVED: Add SHOULD requirement to spec about making sure caret is
visible when text is visible
Received on Sunday, 16 August 2020 11:55:19 UTC