- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 13 Feb 2024 18:12:27 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-anchor-position-1] Can we clarify the `inset-area` syntax? It can be confusing to read and reason about.``. <details><summary>The full IRC log of that discussion</summary> <bramus> TabAtkins: (shows spec with grammar)<br> <bramus> TabAtkins: some time ago una and miriam found that the inset-area property is confusing to read and write<br> <bramus> TabAtkins: they came together and wrote up a few suggestions<br> <bramus> TabAtkins: fantatasai and i looked into and think they are quite right<br> <bramus> fantasai: we came up with some options<br> <bramus> TabAtkins: first one is inset-area-alpha which is what is in the spec<br> <bramus> nsull: do you have an example?<br> <bramus> TabAtkins: see the thread: examples by una<br> <bramus> TabAtkins: were also covered in the slides<br> <bramus> TabAtkins: under i-a-a you would write bottom, center-bottom or bottom center<br> <bramus> TabAtkins: they are all equivalent<br> <bramus> astearns: clarify?<br> <bramus> TabAtkins: one keyword is the row, the other the column<br> <bramus> fantasai: orig concept had a slash to divide both<br> <bramus> fantasai: you had 9 grid, and keyword would say which are you want to cover. very simple if you want 1 part of the grid: keywords and slash in between<br> <bramus> nsull: so top left?<br> <bramus> fantasai: top / left<br> <bramus> fantasai: but with multiple slots there would 2 keywords on one part of the slash<br> <astearns> old spec: left center / top<br> <bramus> TabAtkins: example in old spec: `left center / top`<br> <bramus> TabAtkins: what spec curr says is that would be `center-left top`<br> <bramus> TabAtkins: or flip the order, doesnt matter<br> <bramus> fantasai: dont care about slash vs space vs hyphnes<br> <jensimmons> q+<br> <bramus> fantasai: issue was about not liking the slash and needing to combine keywords<br> <bramus> fantasai: so thats why we need the hyphen now<br> <bramus> fantasai: or we need to introduce some bracketting syntax: span() or [] or …<br> <bramus> … to make clear that you have 2 units: 1 for each axis<br> <bramus> TabAtkins: with span, you could do span(left center)<br> <astearns> ack jensimmons<br> <bramus> jensimmons: getting rid of the slash seems confusing<br> <bramus> … and center is valid for both axis<br> <bramus> … you dont really know which direction<br> <vmpstr> q+<br> <bramus> … hyphenating them can group them indeed, but there’s nothing else in css that does that<br> <astearns> I am liking the named functions to show what the keywords are for<br> <bramus> … slash came from grid: grid-col: 3 /4<br> <bramus> … the slash delineates stuff<br> <kbabbitt> q+<br> <bramus> … dont know why the slash wasnt liked<br> <bramus> … still kind like it<br> <bramus> +1<br> <bramus> miriam: didnt raise issues about the slash<br> <bramus> … proposals happened to remove the slash<br> <bramus> … rest fo syntax was concfusing<br> <nicole> q+<br> <bramus> TabAtkins: once you remove, you dont need another separator<br> <bramus> … only use slash sparringly in css<br> <bramus> miriam: i found 'center left' confusing<br> <bramus> … is it a span(center left) or center row and left column<br> <bramus> TabAtkins: (clarifies on example)<br> <bramus> miriam: the slash only gives you htat if you are explicit about everything<br> <bramus> … (missed)<br> <bramus> … you have to know if there is an implied slash<br> <bramus> … vs one value of center+left<br> <bramus> TabAtkins: when doing center left one would be col and row<br> <astearns> ack vmpstr<br> <bramus> vmpstr: confused by 'center-bottom' and 'bottom center'<br> <bramus> … could this be a shorthand with al longhand like inset-row and inset-column?<br> <bramus> … with area its not really clear which is which (row or col)<br> <bramus> TabAtkins: curr spec now resembels bg-pos<br> <bramus> … unless you need to fill 2 rows or cols you need the dashed keywords<br> <bramus> … with nly 1 you get the current keywords<br> <bramus> … can also not use the inset-earea and use trbl props<br> <florian> q+<br> <bramus> fantasai: if you need only 2 tracks then you need new keywords. not a problem for 1 or 3 (all)<br> <bramus> … had resolved on syntax for bg-pos 4 which includes all logical keywords<br> <miriam> q+<br> <bramus> … both like block-start inline-start type but also x-start and y-start<br> <bramus> … that you can indicate the axies<br> <bramus> … for convenience you can do start start or end end<br> <bramus> … that syntax is in one of the issues<br> <fantasai> -> https://github.com/w3c/csswg-drafts/issues/549#issuecomment-1823607623<br> <astearns> ack kbabbitt<br> <una> q+<br> <bramus> kbabbitt: am I missing sth but wiotu slash `center-start all` is that left chunks or top ones?<br> <bramus> TabAtkins: neither tell you what axis you are on<br> <bramus> … we fall back to standard block and then inline order<br> <bramus> … so center-start is block<br> <bramus> … and all is inline<br> <bramus> … rest of css also follows this order<br> <bramus> … so you have top 6 cells<br> <bramus> kbabbitt: so you fallb ack to implicit ordering<br> <bramus> TabAtkins: only if we can’t really know<br> <bramus> fantasai: (backs that up)<br> <bramus> TabAtkins: with dash keywords the order is clear<br> <fantasai> fantasai: but you could write center-inline-start all, which would make it more obvious<br> <bramus> kbabbitt: maybe we can come up with some ascii art solution?<br> <bramus> TabAtkins: intersting for large regions. only have 3x3 here, so might be ok<br> <astearns> ddack nicole<br> <astearns> ack nicole<br> <bramus> nsull: is center a good keyword? maybe middle for top to bottom? to elimiate one of the cetners?<br> <bramus> TabAtkins: there is precedent for center to be for both axies<br> <bramus> nsull: syntax looks very confusing, hard on authors. both dashes and slashes I found confusing but dashes might be a bit more clear.<br> <bramus> TabAtkins: vast majority of cases is 1 row 1 col, and there its not that steep of a learning curve. 1 keyword and the obvious one for each axis<br> <masonf> One idea for the "two things" keywords: what about adding -and-. So 'center-and-start' or 'center-and-right'.<br> <bramus> fantasai: I think `bottom center-rigth` is a fairly common one<br> <bramus> nsull: and `… center-left`<br> <bramus> fantasai: e.g,. a dropdown that needs to grow out to the side<br> <bramus> … two col is reasonable common I think<br> <jensimmons> q+<br> <jensimmons> q-<br> <bramus> … we can introduce longer logical keywords<br> <bramus> … dont love the hyphenated syntax<br> <bramus> … if we get rid of the slash then we need to do something else<br> <bramus> … open to other ideas<br> <bramus> … need consistency with bg position<br> <bramus> … use same set of keywords<br> <bramus> qq+<br> <bramus> nsull: would there be a way to name the most common cases?<br> <bramus> TabAtkins: specialized keywords are compatible with the current spec<br> <bramus> astearns: and the combos for authors could be stuffed into a variable<br> <bramus> nsull: would be interesting to figure out the most common ones so that its easy on authors<br> <fantasai> scribe+<br> <astearns> ack bramus<br> <Zakim> bramus, you wanted to react to nicole<br> <fantasai> bramus: if inset-area was a shorthand, and the order was fixed, then it would be clearer<br> <astearns> ack florian<br> <fantasai> fantasai: which one is the row and which is the column if you use physical keywords and change writing modes?<br> <bramus> florian: so / has problem what miriam talked about but ohter syntaxes dont<br> <bramus> … one you called alpha and another one you didnt mention<br> <bramus> … you seem to have a preference<br> <astearns> +1 to function names :)<br> <bramus> … what are downsides ofthat other one><br> <bramus> TabAtkins: its more tying: span(…)<br> <bramus> florian: like this one better<br> <bramus> TabAtkins: aesthetic decision<br> <bramus> fantasai: no strong opinion on either<br> <bramus> astearns: i like the span() too<br> <bramus> florian: less typing indeedt hef irst, but unclear about the hyphen when explaining/minuting<br> <emeyer> +1 to Nicole’s point about teaching!<br> <masonf> q?<br> <masonf> q+<br> <astearns> ack miriam<br> <bramus> TabAtkins: grammaticlaly there are similarly complex (missed)<br> <bramus> miriam: can get best of both worlds. confusing part is center: what if we said `bottom span-right`<br> <bramus> … if we take center out of the equaition<br> <bramus> florian: so `span-rigth` is the same as `center-rgith`<br> <bramus> miriam: part of confusion is center meaning two things<br> <chrishtr> xlo,<br> <bramus> … simpler keywords could fix that<br> <vmpstr> +1<br> <bramus> nsull: `span 2`<br> <bramus> TabAtkins: (missed)<br> <bramus> miriam: you could say anchor right?<br> <astearns> s/(missed)/maybe we could use cover?/<br> <bramus> florian: what about 2 rows and 2 cols?<br> <astearns> ack una<br> <bramus> chrishtr: maybe take it back to issue?<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <masonf> q-<br> <bramus> una: important to get right indeed. all want to simplify. first spec was maybe a bit too looose. like changes in v2 as they are more consistent. spaces and slashes were confusing to me, especially with keywords that could be flipped. like idea of `span()` but could be confusing with `span 2` from grid for example<br> <bramus> … need to see how it interacts with rest of css. `span()` would be clear … a function would do that<br> <fantasai> bramus: it's confusing to have a function and keyword with the same name<br> <bramus> astearns: so lets take back to issue<br> <bramus> TabAtkins: could be get resolution on something?<br> <bramus> astearns: seems like people didnt mind the slash<br> <bramus> florian: but the syntax that include the slash had problems<br> <emeyer> I do not mind the slash, but also do not mind a functional syntax.<br> <bramus> TabAtkins: I get why center right can be confusing … any other keyword than center could fix indeed<br> <bramus> fantasai: yes<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9862#issuecomment-1942129089 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 13 February 2024 18:12:30 UTC