– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

<astearns> github-bot, take up w3c/csswg-drafts#11869

[css-forms-1] Checkbox stylesheet missing indeterminate handling

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#11869

astearns: is this only about changing the character thats displayed for indeterminate?

lwarlow: yes, update the content property when its an indeterminate checkmark, and make sure visibility:hidden isnt set when its indeterminate

astearns: sounds good to me, we can also put it in the spec and then people can tell us were wrong

masonf: i think it looks great, just wanted to ask: is it grayed out when its indeterminate?

lwarlow: currently a mixed bag for what browsers do. they alll change the symbol. in chrome its the same color but changes the symbol

lwarlow: other browsers in certain states may do certain things

lwarlow: given the relative lack of color in base ui, change the symbol first and come up with other stuff

lwarlow: disabled state is shown based on that

masonf: +1 from me

proposed resolution: define styling for the indeterminate state that the content is visible and it turns into unicode 2500

RESOLUTION: define styling for the indeterminate state that the content is visible and it turns into unicode 2500

<astearns> github-bot, take up w3c/csswg-drafts#12490

[css-forms-1] Specify readonly input styles

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#12490

lwarlow: currently theres no handling of the readonly state in the css forms spec

lwarlow: if people could think about what readonly should look like

lwarlow: perhaps they should just look like standard controls, perhaps like disabled

lwarlow: we just need to come to a consensus. if it applies in both cases, then we will add a note to the spec that this is deliberate

astearns: for this case, do you have an impression of whether its important that the user styling controls would allow you to achieve the various kinds of styling that we get in the different browsers?

lwarlow: basic css can achieve both of those, theres nothing special we need to introduce

lwarlow: we just need to decide on styles and think about the behavior of things

smaug: does this depend on the operating system? does something happen on macos vs windows?

lwarlow: readonly is a weird one since it doesnt apply to various inputs

<masonf> the HTML readonly attribute is ignored if the type is hidden, range, color, checkbox, radio, file, submit, reset, button, and image

lwarlow: i know it doesnt apply to select and a few other things, so theres weirdness around that side of things as well

lwarlow: i dont know that we want to change which ones it applies to. leaving it as-is is probably ok

annevk: whether it can be readonly seems like an html question. we should just decide how its going to be styles. whether its focusable or not, thats more of an os parity question

masonf: it probably shouldnt change that list - readonly doesnt change whether its focusable. its an a11y question, right? you want to focus it and see that its readonly??

annevk: also the focus outline is up to the ua so that we dont have to consider either for any other things

annevk: and the text caret, i dont know

annevk: is styling of text carets a thing? i think thats also up to the browser

lwarlow: you can change the color and animation

lwarlow: chrome also has caret shape

<astearns> https://drafts.csswg.org/css-ui-4/#the-insertion-caret

annevk: that should work but whether it shows in a readonly control or not, that doesnt seem like ... its an interesting question but out of scope

masonf: you said in the issue that chromium renders a text caret on windows, i just tried on mac and it doesnt

lwarlow: no i tried on mac

zcorpan: the mouse cursor turns into an i beam if you hover, but when you click theres no caret

masonf: the i beam is because you can still select/highlight

masonf: im in favor of leaving it as is because the behavior becomes clear when you try to type in it, you dont get a caret

lwarlow: im happy to resolve on that

lwarlow: we can revisit and come back to this if theres cases where browsers disagree

astearns: resolving then to close this issue no change?

lwarlow: yes

lwarlow: i might add a note to the spec, but normatively no change

masonf: css forms has no styling for the readonly state? then yeah i agree

proposed resolution: close this issue no change, can revisit if needed

RESOLUTION: close this issue no change, can revisit if needed

<astearns> github-bot, take up w3c/csswg-drafts#13383

[css-forms-1] option hover/active styles inside of disabled select listbox

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#13383

lwarlow: you can have a disabled select and still get hover/active styles on the options

lwarlow: it turns out that option elements get their enabled state from themselves and from parent optgroups, but not from the select element itself

lwarlow: one possible fix here is to add the enabled pseudo-class to the select inside of the styles and then it has to be an enabled select and an enabled option

lwarlow: anne pointed out that this is wrong behavior to start with, and options should be disabled when sleect is disabled

lwarlow: does seem to apply to auto appearance

lwarlow: if you hold down on an option in a disabled listbox you get an active style as well

dbaron: i looked into this a few days ago because joey wrote a patch to do this styling, and my impression is that if we can make it so options inherit disabled state from select that would be nice and it seems to make sense

dbaron: the selectors you need to get this all correct combine with all of the weird specificity things you have

dbaron: getting styles for disabled options correct if you have to look at the select disabledness too is a huge mess

dbaron: maybe its not a huge mess if you rewrite all the styles for selects and options to have enabled/disabled, but if you dont do that then its bad, maybe theres a nicer way to write it

dbaron: looking at what the stylesheet looks like today, its not a small change

<masonf> jarhar: I posted a few issues about this. About making options disabled when their select is disabled.

<masonf> ...there are problems with the initial selection algorithm.

<masonf> ...in order to not break that, Anne suggested changing the selectors for the options to incorporate the ancestor select being disabled.

<masonf> ...but the other algorithms could still use the "old" disabled.

annevk: yeah we have locally disabled and globally disabled or something

masonf: and locally disabled is only used for this stylesheet?

annevk: other way around. locally just looks at optgropu and option as it does today. then we create a new one that look at the ancestor select in addition, and that one we use for enabled

masonf: that was going to be my question for doing that for auto, i assume we dont want to do something different for auto vs base

annevk: what option you show is something we have to preserve

masonf: id be concerned about changing any selector on select matches because theres so many

<dbaron> +1 to trying the global/local thing and changing what :enabled/:disabled do on options

lwarlow: this only applies to listboxes

dbaron: isnt it true that you cant see the options if the select is disabled and its a dropdown?

masonf: that makes me feel better

keithamus: you mentioned that options get their disbaled state from optgroups. im surprised. should we fix this for optgroups too?

keithamus: we could resolve two at once. options should look at their optgroup or select, and optgroups should look at select

<lwarlow> +1

<masonf> +1

<masonf> jarhar: to Mason's point about compat, I imagine it could affect existing appearance:auto UA styles, but we can probably fix it

<masonf> ...or we could add an internal pseudo class or something.

<dbaron> (it also might be that the changes are an improvement!)

<masonf> ...I don't remember how optgroup disabled works, but it probably doesn't do what we just discussed. But we could change it. SGTM

astearns: i did notice the PRs at the end of the issue

astearns: where is the spec with regards to this issue at the moment?

<masonf> annevk: nothing landed yet

proposed resolution: make the enabled and disabled pseudo-classes for options and optgroups look at their ancestor select, and keep other algorithms which look at option disabled-ness keep using the current "local" definition which doesn't look at the ancestor select for compat reasons

<lwarlow> +1

<dbaron> +1

<masonf> +1

<keithamus> +1

astearns: so these algoriths are not exposed to css?

jarhar: correct

astearns: im concerned that we would have two different answers to the question is this option disabled depending on how you approach getting your answer

astearns: if you get it from the pseudo, sure its disabled

astearns: but if you use this js mechanism to determine which option to be checked, then its not disabled

<zcorpan> https://html.spec.whatwg.org/#selector-disabled

astearns: having two answers seems like a code smell to me

keithamus: the presence of the attribute is another thing

keithamus: from developer perspective theres nuance here

keithamus: in css if you use an attribute selector instead of a pseudo selector you get different answers

annevk: is there a js api?

lwarlow: it changes the algorithm of which option is selected by default, thats a js way you could detect the difference

annevk: there is a lot of callers for disabled

masonf: the point of alans question is whether theres an easy js way to check this

lwarlow: options have a disabled property

annevk: that reflects the attribute

masonf: that could be a source of confusion

annevk: it already is because of optgroup

zcorpan: im not sure we should change optgroup. the html spec doesnt have the disabled state for optgroup. theres the disabled attribute, but the disabled state doesnt apply to optgroup itself

annevk: presumably the enabled pseudo class does apply right?

zcorpan: yes, but it looks at the attribute instead of the state

annevk: it doesnt have the disabled state because nothing else uses it

keithamus: it seems confusing to me that you could query for enabled and youd get optgroup in a disabled select

keithamus: and you wouldnt get any of the options

zcorpan: i dont disagree, its strange. im not sure its worth fixing

zcorpan: and risking web compat

annevk: for optgroup theres less risk than option

keithamus: its also whether the spec has a concept for disabled. certainly in firefox it has disabled. it has something that is disparate from select

lwarlow: go with the proposed resolution and come back if theres compat issues?

<jarhar> +1

lwarlow: if i get the compat concerns id balance them against wanting base appearance to have a sane set of behaviors. like keith mentioned, if you look for enabled descendants and you get optgroups thats pretty weird

masonf: would it reduce the chance of breakage if you change disabled to reflect this as well? option.disabled would return true if its parent

lwarlow: from my perspective thats riskier

lwarlow: disabled is already a reflection than actually reflecting the internal state

<dbaron> I agree with Luke that it sounds riskier.

lwarlow: i would be fine, it makes sense

astearns: we could make it separately

<dbaron> (I think it makes sense for .disabled to continue to be attribute reflection, so I don't think it makes sense...)

<masonf> jarhar: I also don't like changing the disabled IDL, because it's writable. What happens if you set it to true on an inherited disabled option.

<masonf> ...it should stay.

<masonf> masonf: that's a good point

zcorpan: if theres use case for reading the actual state like actually disabled

zcorpan: disabled for real

<masonf> .actuallyDisabledV2

<lwarlow> Fwiw that would be fine you'd just do [ReflectSetter] and then a custom getter if we did want to do that

<masonf> jarhar: {missed, sorry}

keithamus: its also not the first thing we have to use matches to query something. for popover you have to use matches

astearns: anne, are you convined that we can change optgroup?

annevk: i think we should do both

proposed resolution: make the enabled and disabled pseudo-classes for options and optgroups look at their ancestor select, and keep other algorithms which look at option disabled-ness keep using the current "local" definition which doesn't look at the ancestor select for compat reasons

<masonf> +1

<lwarlow> +1

<dbaron> +1

<zcorpan> +1

RESOLUTION: make the enabled and disabled pseudo-classes for options and optgroups look at their ancestor select, and keep other algorithms which look at option disabled-ness keep using the current "local" definition which doesn't look at the ancestor select for compat reasons

<astearns> github-bot, take up w3c/csswg-drafts#13527

[css-forms-1] Find a way to avoid double border between ::picker() and button

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#13527

<lwarlow> 1+

fantasai: we were thinking that the thing that probably makes the most sense is an anchor positioning feature that has been resolved on but hasnt made it into the spec yet which tells which box you want to anchor to. default is border box, for a select it might make sense to anchor it to the padding edge in the block axis so that looks like the

picker menu is actually coming from the ?? that was the idea

fantasai: the downside of that is that there are some designs that want it to look outside to outside

masonf: that is a new property?

fantasai: yes, position-anchor-box i think

fantasai: alternative is to put -1 margin on it

fantasai: which would overlap the 1px border

lwarlow: margin -1 i think would be a massive code smell for base appearance. you shouldnt need to do that kind of margin hack in the base styles

lwarlow: ideally we should be setting properties that we need to set, but we shouldnt set more than that

lwarlow: margin -1 feels slightly weird

lwarlow: the other thing with changing to the padding box would be better

lwarlow: it looks less weird

lwarlow: i will say that would break my existing select

lwarlow: the picker has its top border set to 0 width, and if you change it to anchor against the padding box that will overlap with the buttons border such that there will be no border

astearns: the padding box could be overriden in your case

lwarlow: yes but it doesnt at the moment and it works in production, thats the point - it could break designs

lwarlow: i suspect that design does exist in the wild already, but probalby not too much

lwarlow: thats worth being aware

lwarlow: with the proposed change from openui, where potentially select wont have a border radius, i guess this issue still occurs, but is it less bad?

lwarlow: you still end up with the double border

masonf: we did resolve to remove border radius last week. we also resolved to add an issue to a non weird looking criteria to the design principles

masonf: its fully functional, it just looks weird to most people

masonf: we should just prefer fewer rules to more rules. each rule is a thing for a developer to go undo

masonf: personally i think that if somebody puts out a reset stylesheet for base appearnace then its a failure on us

masonf: it should be minimal enough that its a reset

masonf: here, if the fix for this is to use a new property that doesnt even exist yet, that feels even worse, the reset sheet is growing

masonf: if theres a change that can be made in the existing set of properties, maybe thats better, but then i worry about compat as luke mentioned

masonf: primarily my objection is the growth of the ua stylesheet

astearns: i agree with luke, having a -1 hack to solve this doesnt sound right

astearns: contra masons concerns about keeping things simple, the proper way to do that would be have a variable

astearns: do we have css variables in the ua stylesheet? should we never put them in there?

fantasai: yes

zcorpan: variable doesnt solve the problem - if the author sets the border to zero, you still have a mismatch even if the ua stylesheet has a variable

masonf: unless the devleoper could change the variable

keithamus: i wonder if theres a more generalized way to solve this, and i think designers often come to these issues with segmented buttons where they want buttons in between buttons to not have borders

<lwarlow> They're custom properties as well not variables ;) so the UA property is just a property.

keithamus: could css have a border collapse? these two elements, if there adjacent, one of their borders should collapse

keithamus: probably a wild idea, but it would have utility beyond select

fantasai: i think what you want is position-anchor-box

fantasai: not true in the general case where you ahve a sibling relationship, tables do border collapsing

fantasai: in this case theres not a parallel relationship, its dependent. you want to overlap the anchors border then you should anchor to its box

astearns: i agree that seems to be the ideal mechanism, but it isnt implemnented and not even specced yet, so i worry about relying on that

astearns: even though we are going to have a principle about not being weird, thats just one principle to balance against the rest

astearns: it might be minimal enough that we decide to elave the double border as weird until we get this anchor positioning mechanism widely supported, and then look at changing the ua stylesheet

masonf: we havent decided to add a non weird thing, we opened an issue to discuss which i will be against

masonf: keep the web weird, i dont think that should be a criteria

<lwarlow> The longer we leave it the larger the compat issue is worth being aware of.

masonf: what you said is right, this property doesnt exist yet

masonf: developers who think this looks weird can use the property

masonf: as we add new stuff to the web, devleopers can use it

masonf: you can use it on customizable select but you dont have to break the web

<lwarlow> +1

keithamus: regarding adding the feature later, luke you said that something would break? if were saying we can do this eventually that becomes more of a problem as implementations start to ship

zcorpan: the double border probably only looks weird when the borders have the same color. if they are different, then maybe the opposite looks weirder

<masonf> I think the black border looks weird. It should be hotpink.

<masonf> jarhar: those two borders technically have different colors. The select element inherits its color, and the picker sets CanvasText. They happen to be the same.

<lwarlow> Maybe we can resolve no change?

<masonf> +1

<zcorpan> +1

fantasai: we can come back to this when anchor box stuff is specced

<lwarlow> A can kick is a no change for now at least I guess

astearns: as keith mentioned, we may not be able to use the new thing depending on how long this sticks around

masonf: we should open an issue for changing the ua stylesheet over time when new stuff is added

astearns: we already have a basic principle of not breaking the web and consider bakcwards compat

astearns: in a case by case basis, there may be a way to update base styles that doesnt have compat concerns

proposed resolution: close this no change for now

<masonf> +1

fantasai: ill take that back to the team and look at speccing stuff we had decided a couple years ago

astearns: this anchor thing has been waiting for that long?

<lwarlow> +1

RESOLUTION: close this no change for now

annevk: maybe lets not resolve on that for now, we want to check back with the team

proposed resolution: strike that and just leave the issue as-is for now

<lwarlow> +1

<keithamus> +1

RESOLUTION: strike that and just leave the issue as-is for now

<masonf> proposed resolution: cancel daylight savings globally

end