w3c / csswg-drafts Goto Github PK

WebKit's implementation supports using a string after @keyframes and animation-name. Blink supports this syntax for prefixed stuffs but not for unprefixed ones.

We've seen a website depends on this syntax (webcompat/web-bugs#2337). Not sure how widely this kind of thing is used, but in general, I guess it is not a bad idea to accept string as animation name.

I raised this for the compat spec (whatwg/compat#43) but it'd probably better to be discussed in CSSWG.

https://github.com/dbaron/gather-doc-email might be useful

On Mon, May 23, 2016 at 12:38 PM, Athanasios Viennas [email protected] wrote:

Dear folks at w3c,

I wonder what is the purpose of "removing" upper-greek value from list-style-type property (https://www.w3.org/wiki/CSS/Properties/list-style-type) between CSS1 and the modern versions. I honestly wonder who decided this and on what requirement, have you estimated the impact on the WWW as a community and the practical disabilities it has caused, and how about the trend of web standards directing towards multilingualism.

Can you please provide any pointers on the related minutes of the meetings supporting the given decision.

Copying this over from http://lists.w3.org/Archives/Public/www-style/2016Apr/0294.html
(Disclaimer: My opinions are my own, not my employer's.)

:read-only is currently spec'd as (basically) :not(:read-write), and :read-write is currently spec'd as matching:

• <input> elements to which the readonly attribute applies, and that are mutable (i.e. that do not have the readonly attribute specified and that are not disabled)
• <textarea> elements that do not have a readonly attribute, and that are not disabled
• elements that are editing hosts or editable and are neither <input> elements nor <textarea> elements (i.e. contentEditable / designMode)

(A) This leads to an anomaly: Some inputs that the user can interact with to alter their "value" (which most folks would thus casually deem "writable") match :read-only instead of :read-write.
Namely, <input>s of type range, color, checkbox, radio, and file are :read-only since the readonly attribute doesn't apply to them.
(One can argue that this is a bug in HTML and that HTML should just allow the readonly attribute on these input types.)

(B) There's a question of whether the buttonish <input>s (types: image, submit, reset, button) should be :read-only or :read-write. Arguably, they should be :read-only since the user cannot normally directly modify their values. They are interactive insofar as they're clickable, but they aren't editable. However, Chrome and Edge currently have them matching :read-write, which doesn't conform with the current spec.

(C) There's a question of whether <input type="hidden"> should match :read-only or :read-write or neither. Per spec, it currently matches :read-only. But in Chrome and Edge, it currently matches :read-write.

(D) I think there's some question as to how useful the contentEditable case is, particularly when it's lumped together with the form input cases.

Current state of affairs (FWICT):

• WebKit matches the current spec and doesn't want to change their implementation until the spec itself is changed.
• Blink and Edge both suffer from 2 bugs relative to the current spec:
  • :read-only doesn't match <input>s to which the readonly attribute does not apply
    • https://bugs.chromium.org/p/chromium/issues/detail?id=604154
    • https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7229941/
      • As stated in a comment and on the www-style thread, the Edge folks (understandably) don't think the spec's current behavior here makes sense.
  • :read-write shouldn't match <input disabled> or <textarea disabled>
    • https://bugs.chromium.org/p/chromium/issues/detail?id=604117
    • https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7226201/
    • (Gecko's prefixed implementation also suffers from this bug)
• Gecko currently only has a prefixed implementation. Relative to the current spec, it has the one aforementioned bug.
  • Feature request / unprefixing bug: https://bugzilla.mozilla.org/show_bug.cgi?id=312971

And in light of the lack of compatibility and questions about the utility of these pseudos as-then-specd, it looks like Hixie asked the spec editors ~3 years ago in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17812#c24 whether :read-only & :read-write could be removed from the spec altogether, but he never got a reply.

@zcorpan @FremyCompany @makotokato @BenjaminPoulain @tabatkins @fantasai

As discussed: https://lists.w3.org/Archives/Public/www-style/2015Oct/0226.html (item 8)

This will probably involve editing all the CSS specs that use this line and updating terms in CSS transitions too.

Can we have selector for overwrite mode? If we have a selector for overwrite mode, we could write:

input, textarea, *[contenteditable=true"]:overwrite { caret-shape: block}

As discussed: https://lists.w3.org/Archives/Public/www-style/2015Oct/0226.html (item 6)

Could you update https://twitter.com/CSScommits, so that it includes links to the GitHub commit instead of hg.csswg.org? For example, link to e045549 instead of https://hg.csswg.org/drafts/rev/dcf65922dc5c.

The diff highlighting on GitHub is better because it shows you which specific parts of a line have been added/removed.

We should invoke "parse error" everywhere EOF is reached but it was not expected, like when ) is omitted from a function.

First, original proposition, https://lists.w3.org/Archives/Public/www-svg/2013Dec/0080.html

Yes, I'm trying to bring this to the table again as it did not seem to get much attention/discussion the last time around.
-maybe being on Github will be more conducive to discussion..

I really agree with this proposal,
being able to modify the viewbox on a SVG element using CSS would allow for very useful applications of SVG in a responsive layout, (See Sara Soueidan's examples below)

Sara Soueidan has a very good article demonstrating a perfect need and use cases for this here: https://sarasoueidan.com/blog/svg-art-direction-using-viewbox/

There were some enthusiastic responses from some SVG heads..

@sdras Sarah Drasner Mail List Reply

@AmeliaBR Amelia Bellamy-Royds Mail List Reply

@jakearchibald Jake Archibald Mail List Proposal

As was discussed in the past, and most recently championed by Rachel Nabors, steps() is defined in a nonintuitive way. Depending on whether you use "start" or "end", you never actually see the starting/ending value. If you do want to see both the starting and ending values, and have a stepped transition between them, you need to do some math and overshoot the desired end-point instead. This is extremely common; for example, the default "discrete" method that we use for things without a better interpolation method is exactly this! This also shows the weakness of the hack - for non-interpolable values, you can't "overshoot" either.

It was suggested that we add a new function that handles things more intuitively, so that saying you want "2 steps" creates a timing function that spends half the time on the starting value and half on the ending value, "3 steps" spend a third of time at the start, a third in the middle, and a third at the end, etc.

The name frames() was suggested for this and proved popular in Rachel's group of authors, by analogy with animation frames. It takes a single <integer> which must be >= 2.

See, e.g.:
https://lists.w3.org/Archives/Public/www-style/2014Dec/0340.html
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28053

There is a note about the interaction between initial-letter and ruby, but I don't think that is the solo case. The height of line can be changed by any inline element, e.g. a span with larger font, or an big inline <img>. This indicates that there is actually a cyclic-dependency.

I think it should rely on something computable from CSS values, rather than the layout result. Probably the computed line-height value or the "step unit" defined in CSS Step Sizing.

The combinators and multipliers within the syntaxes should link to the CSS Values module like other modules.

Sebastian

See thread beginning: https://lists.w3.org/Archives/Public/www-style/2016Apr/0107.html

CC @tabatkins @SimonSapin

https://drafts.csswg.org/css-syntax/#css-stylesheets says

The prelude of the qualified rule is parsed as a selector list. If this results in an invalid selector list, the entire style rule is invalid.

The prelude of a qualified rule is a list of component values, and I can't find any prose that defines how to parse that into a selector.

(Pedantic, I know, but this is much less well-defined than the rest of the otherwise well-written spec.)

The combinators and multipliers within the syntaxes in CSS Text 3 should link to the CSS Values module like other modules.

Sebastian

Hi there. I am not sure I understand how fixed table-layout works in some edge cases (and given the docs I can find online I am not the only one).

TLDR: The ask is for browser vendors to have a look at how table-layout:fixed works in their browser. Particular attention is needed for these cases: width:auto; width:min-content; width:max-content; float:left; position:absolute; when the sum of column widths overflow the table width; when some columns do not have a <td> or <th> in the first row, but are required by later <tr>...<td>; I am interested in all behavior involving table-layout:fixed at this point.

So, lets start by one definition that clearly does not match implementation:

According to MSDN:

You can optimize table rendering performance by specifying the table-layout property. This property causes the table to be rendered one row at a time, providing users with information at a faster pace.

The table-layout property determines column widths for a table in the following order:

• By using information in the width property for the col or colGroup element.
• By using information in the width property for the td elements in the first row.
• By dividing the table columns equally, regardless of the size of the content.

If no width is specified for the table, it renders by default with width=100%.

If the content of a cell exceeds the fixed width of the column, the content is wrapped or, if wrapping is not possible, it is clipped. If the table-layout property is set to fixed, the overflow property can be used to handle content that exceeds the width of a td element. If the row height is specified, wrapped text is clipped when it exceeds the set height.

Setting the property to fixed significantly improves table rendering speed, particularly for longer tables. Setting row height further improves rendering speed, again enabling the parser to begin rendering the row without examining the content of each cell in the row to determine row height.

Then how do we explain this test case:

• https://jsfiddle.net/9m8ccz2h/
• https://jsfiddle.net/9m8ccz2h/1/

I think the reason is that no browser apply the 10.3.3 algorithm when the width of the table is auto, and therefore use normal layout (initially I thought Firefox also did an exception if the width of the cells of the first row is explicit (example /3/ here), but it looks like to be a difference in the general sizing algorithm instead).

• https://jsfiddle.net/9m8ccz2h/2/
• https://jsfiddle.net/9m8ccz2h/3/

Closer definitions

According to MDN:

Table and column widths are set by the widths of table and col elements or by the width of the first row of cells. Cells in subsequent rows do not affect column widths.

Under the "fixed" layout method, the entire table can be rendered once the first table row has been downloaded and analyzed. This can speed up rendering time over the "automatic" layout method, but subsequent cell content may not fit in the column widths provided. Any cell that has content that overflows uses the overflow property to determine whether to clip the overflow content.

According to CSS 2.1:

With this (fast) algorithm, the horizontal layout of the table does not depend on the contents of the cells; it only depends on the table's width, the width of the columns, and borders or cell spacing.
The table's width may be specified explicitly with the 'width' property. A value of 'auto' (for both 'display: table' and 'display: inline-table') means use the automatic table layout algorithm. However, if the table is a block-level table ('display: table') in normal flow, a UA may (but does not have to) use the algorithm of 10.3.3 to compute a width and apply fixed table layout even if the specified width is 'auto'.

In the fixed table layout algorithm, the width of each column is determined as follows:

• A column element with a value other than 'auto' for the 'width' property sets the width for that column.
• Otherwise, a cell in the first row with a value other than 'auto' for the 'width' property determines the width for that column. If the cell spans more than one column, the width is divided over the columns.
• Any remaining columns equally divide the remaining horizontal table space (minus borders or cell spacing).
• The width of the table is then the greater of the value of the 'width' property for the table element and the sum of the column widths (plus cell spacing or borders). If the table is wider than the columns, the extra space should be distributed over the columns.

If a subsequent row has more columns than the greater of the number determined by the table-column elements and the number determined by the first row, then additional columns may not be rendered. CSS 2.2 does not define the width of the columns and the table if they are rendered. When using 'table-layout: fixed', authors should not omit columns from the first row.
In this manner, the user agent can begin to lay out the table once the entire first row has been received. Cells in subsequent rows do not affect column widths. Any cell that has content that overflows uses the 'overflow' property to determine whether to clip the overflow content.

Remaining questions

Now, what to do when the width of the table depends on the content is another question. Firefox ignores the fixed algorithm as if the width was auto for max-content, set width:0 for min-content. Chrome set width:0 for both cases (Edge does not support those):

• https://jsfiddle.net/9m8ccz2h/4/ (might require adding prefix)
• https://jsfiddle.net/9m8ccz2h/5/ (might require adding prefix)

The final bit that was left undefined was how other columns that are not in the first row are rendered.
It looks like they are with width set to 0 in all browsers:

• https://jsfiddle.net/whbkd7fz/
• https://jsfiddle.net/whbkd7fz/1/

Call for action

I'm going to check whether all the previous assumptions holds true in EdgeHTML, but I would like other browser vendors to chime in in this case to assert there is no other special case where they apply the fixed algorithm anyway. Nobody seemed to apply it when floated or absolutely positioned (should behave like width:min-content), though in the latter case browsers didn't agree on the 100% table width.

Cc: @dbaron + @tabatkins ?

WebKit/blink have "overflow: overlay" to enable scrollbars that don't take up layout space. Back in 2013 Tab said he supported standardization of this.

IE/Edge has '-ms-overflow-style: -ms-autohiding-scrollbar' which does the same but also indicates that scrollbars should automatically hide when not in use. Note that many sites try to implement this themselves today based on mouseenter/mouseleave events, which breaks touchscreen scrolling.

I don't know all the history here, but does CSSWG want to consider standardizing something here?

This bug tracks potential removal in blink.

Hey @frivoal , I opened this specifically to begin the discussion stated in the minutes regarding other controls that generated content with a value of ImageType and appearance with a value of none works as a replaced image but retains its functionality.

See, for example, the example at the end of: https://lists.w3.org/Archives/Public/www-style/2014Sep/0055.html

I discovered this today when my overflow content appeared cut-off in Firefox and IE. It appears this was reported to Mozilla and closed as invalid in Bug 748518 - padding-bottom/right(block-end/inline-end) is ignored with overflow:auto/scroll because it extends in from the border-box rather than out from the scrollable area and someone there suggested bringing it up with the CSS team. I did a search for padding-bottom overflow on the www-style list and didn't see anything.

Previous practical discussions on Stack Overflow include Bottom padding not working on overflow element in non-chrome browsers and padding-bottom is ignored in Firefox and IE on overflowing elements with no content.

Perhaps this is already clear and Chrome has it wrong? I'll admit I'm not enough of an expert on the spec to be sure, just hoping for consistency.

https://drafts.csswg.org/css-scoping/#scoping-markup names the scoped attribute on HTML’s <style> element as example for scoping markup and references the WHATWG HTML spec, but the attribute has been removed from HTML in both WHATWG’s and W3C’s version.

whatwg/html#552
w3c/html#231

On a side note, is there hope that the very useful @scope CSS rule will be implemented by browsers or is scoping completely dead?

The combinators and multipliers within the syntaxes should link to the CSS Values module like other modules.

Sebastian

It looks like recent versions of Edge and Chrome support the properties background-repeat-x and background-repeat-y. I haven't checked how far back support goes. Gecko does not support them, and Webkit doesn't appear to either.
If this is something people want, then it should be added to the spec.

On https://drafts.csswg.org/css-fonts/, Firefox shows a padlock with a yellow warning sign because the document contains an <img> element with src="http://www.w3.org/Icons/w3c_home". That src should be HTTPS.

I’d send a pull request, but that image is not present in Fonts.src.html and I didn’t find how it gets added to Fonts.html.

CC @nattokirai

Are there any plans to specify calc behavior for widths and heights in table layout?
Implementations varies across browsers (http://jsbin.com/juqafi/1/edit?html,css,output)

Given the complexities of width and height calculations on table cells and table elements, math expressions involving percentages for widths and heights on table columns, table column groups, table rows, table row groups, and table cells in both auto and fixed layout tables MAY be treated as if auto had been specified.

I suspect the complexity of the math grows when it comes to mix unit (personally, I feel it's just a set of mathematical equations, to be solved in not more sophisticated way that sizing algorithm for Grid Layout).

However, I would say that expressions like:

• calc(10% + 20%) http://jsbin.com/juqafi/1/edit?html,css,output
• calc(100%/7) https://bugzilla.mozilla.org/show_bug.cgi?id=957915

Should be really easy to compute, resolve, and apply.

The combinators and multipliers within the syntaxes in CSS Text 3 should link to the CSS Values module like other modules.

Sebastian

please ignore

The combinators and multipliers within the syntaxes should link to the CSS Values module like other modules.

Sebastian

As discussed: https://lists.w3.org/Archives/Public/www-style/2015Oct/0226.html (item 7)

As discussed: https://lists.w3.org/Archives/Public/www-style/2015Oct/0226.html (item 5)

As resolved: https://lists.w3.org/Archives/Public/www-style/2015Oct/0226.html (item 1b)

As resolved here: https://lists.w3.org/Archives/Public/www-style/2015Oct/0226.html (item 1a)

Update: Current proposal is for an @when and @else rule, and is located at https://tabatkins.github.io/specs/css-when-else/

From @frivoal:

During the face to face, we talked about the fact setting default styles outside of a media query, then undoing then in the media query before applying new ones is painful, and that authors often want to do something like if/else.

I suggest we go with this syntax:

@media (something) {
 ...
 ...
 ...
 @else {
 }
}

@supports (foo:bar) {
 ...
 ...
 ...
 @else {
 }
}

I think putting the else inside the conditional rather than following it, is more consistent with how things work in CSS, since we don't currently have a concept of associating two separate @rules.

The transition phase isn't too nice, as this isn't really usable until all browsers support it, but I think this is going to be the case for any syntax we can pick for this feature.

Thoughts?

See: #42

Here I described suggestion. I think this is theme of CSS4.
w3c/css-houdini-drafts#130

Copy:

Hello. I suggest make very original feature: CSS background shaders. And shaders of OpenGL ES 3.0. Also, I suggest forbid use vertex shaders, only fragment. If this is theme of CSS4, please, merge this suggestion to CSS4 (or CSS4.1).

Syntax:

  background-image: custom( /* Forgot CSS custom filter (shaders) syntax */ );

Features:

• Same syntax as CSS custom filters
• Shaders used for painting
• Not require JS
• Much faster
• Much powerfull

https://drafts.csswg.org/css-align-3/#baseline-align-content
"minimum necessary extra space is added between its start (end) content
edge and its alignment subject’s edge to align its alignment baseline
in that axis"

What should happen when the alignment subject has box-sizing:border-box
and a max-[width|height] in the relevant axis, and adding "minimum
necessary extra space" to meet the baseline would exceed the given
max size?

I can't find anything in the CSS Align spec that says anything about
this case.

I can think of a few alternatives:
A. add padding up to the max size and then add margin after that
(honor both baseline alignment and the given max-size, but not
align-self)
B. add padding up to the max size
(honor the given max-size and align-self, but not baseline
alignment)
C. ignore the max size
(honor align-self and baseline alignment, but not the max size)

"Percentages: refer to width of background positioning area minus height of background image"

It should be "minus width of background image".

As discussed here: https://lists.w3.org/Archives/Public/www-style/2015Oct/0226.html (item 4)

https://lists.w3.org/Archives/Public/www-style/2012Nov/0261.html

Hello!

I don't really know if this is the correct place to post suggestions, but I will do it anyway.
If this isn't the correct place, please correct me and tell me where I have to post my suggestion.

Ok, so yeah, I've been working on my web-app and there are a few things I don't like about the scrollbars. My biggest problem is, that I have no possibility to style my scrollbars properly. In Chrome / webkit are a few options, but they are prefixed and not supported in all browsers.
As well as the "Overflow: overlay" spec.

So my suggestions are the following:

Webkit did already a good job on styling scrollbars with pseudo elements, so why don't accept them as a standard:

selector:-webkit-scrollbar
selector:-webkit-scrollbar-button
selector:-webkit-scrollbar-track
selector:-webkit-scrollbar-track-piece
selector:-webkit-scrollbar-thumb
selector:-webkit-scrollbar-corner
selector:-webkit-resizer

I like the idea of the different states too

:horizontal
:vertical
:decrement
:increment
:start
:end 
:double-button
:single-button
:no-button
:corner-present
:window-inactive

If you don't know the styling possibilities in webkit, please check this article: https://css-tricks.com/custom-scrollbars-in-webkit/

There is something I really don't like, its the "overflow: overlay" property.
If you don't know the "overflow: overlay" property, follow this link: http://quirksmode.org/css/css2/overflow.html

Basically the overflow property is there for deciding if the element should have a scrollbar or not.
These are the standard values which all browsers support:

visible - content is not clipped, thats why there cant be any scrollbars
hidden - content is clipped but without scrollbars
scroll - content is clipped but with scrollbars (always visible)
auto - the content is clipped but with scrollbars (visible if content is overflowing)

And now the overlay value:

overlay - content is clipped, scrollbars are always visible but are rendered above the container

This kind of value isnt ment to be in the overflow property, it should be a styling option for the ":-webkit-scrollbar" pseudo element:

selector:-webkit-scrollbar {
position: absolute;
}

This would be equal to the "overflow: overlay" property.
Unfortunately the ":-webkit-scrollbar" pseudo element currently doesn't accept the "position" property.

In short:
The idea is to implement scrollbars as pseudo elements on elements which are displaying scrollbars by the correct setting of the property "overflow". On the pseudo element ":-webkit-scrollbar" the property "position" can be applied for custom positioning and achieving of the "overflow: overlay" effect. In the final standard the pseudo elements should work without any prefix of course.

I hope you understand my idea of scrollbar styling and the, in my opinion obsolete property "overflow: overlay". Any feedback to my suggestion is highly appreciated! :)

Best regards!

People may need to use viewport units in a writing-mode-aware way, so probably we should add logical equivalents for vw and vh. They could be called vis and vbs or something like that.

I'm trying to understand what bullet 3 here means:
https://drafts.csswg.org/css-grid/#grid-baselines

What does "failing that" mean there? I read it as, "if there
are no grid items", but I don't know if you mean synthesizing
a baseline from a grid item can fail in some way. Furthermore...

https://drafts.csswg.org/css-align-3/#synthesize-baselines
"To synthesize baselines from a rectangle (or two parallel lines),
synthesize the alphabetic baseline from the lower line and the central
baseline by averaging the positions of the upper and lower lines."

I don't understand what precise code I should write to implement
this paragraph. Does "averaging the positions" mean I should take
the distance between the two lines and divide it by 2 to get
the alignment baseline to use? IOW, the synthesized baseline of
a content box is the center of the content box in the relevant axis?

https://drafts.csswg.org/selectors-4/#matches contains these paragraphs:

Default namespace declarations do not affect the compound selector representing the subject of any selector within a :matches() pseudo-class, unless that compound selector contains an explicit universal selector or type selector.

As with :matches(), default namespace declarations do not affect the compound selector representing the subject of any selector within a :matches() pseudo-class, unless that compound selector contains an explicit universal selector or type selector.

The second paragraph doesn't make sense here. :not() has a similar paragraph, so perhaps this one was intended for :has()?

Pardon for propose. We have difficulties with rendering element(). I speaked with Chromium devs, I understand that they can only render: canvas, video or img i.e. paint source based. I beg to divide element() to low level functions: subject (i.e. element() that capture from DOM) and source() (that capture from CSS.elementSources i.e. paint sources). For me really difficult understand element().

https://github.com/w3c/csswg-drafts/tree/master/css-images-4
PLEASE! Merge Paint Sources spec to source().

Copy:
https://lists.w3.org/Archives/Public/www-style/2015Dec/0197.html

test mailing list integration

In https://drafts.csswg.org/css-values/#absolute-lengths , in the sentence:

The absolute units consist of the physical units (in, cm, mm, pt, pc, q)

The ‘in’ unit (inches) is incorrectly hyperlinked to the ‘in’ compositing operator of the Filter Effects Module.

The combinators and multipliers within the syntaxes should link to the CSS Values module like other modules.

Sebastian

After another session of fruitless wrestling with fonts, i thought i should make sure (a) i'm not missing something obvious, and (b) if not, ask whether we can improve CSS.

This time i was trying to get a particular look across Mac- and Windows-based browsers. On the Mac i like the look of Helvetica Neue with font-weight set to 300 at a font size of 16px. But i can't find anything to match that in Windows standard fonts – well, i could get reasonably close, but i'd need to be able to change the font weight and the font size for a font-family name specified as a fallback.

I've never understood why, in CSS, i can't say something like

p {
	font: 'macfontname' 300 16px, 'windowsfontname' 500 18px, sans-serif;
}

This is a much bigger problem in non-Latin scripts, where glyph dimensions can vary widely from font to font at the same font-size. For example, compare the same glyphs set to the exact same font-size in Mongolian Baiti and Noto Sans Mongolian:

It's not just mongolian, this is a constant problem in arabic, and many other scripts.

And by the way, i thought about web fonts, but i can't help thinking that you should be able to just use standard platform fonts if you want to. Note that that tweaking the size/weight of such fonts would be easier than finding fonts that look good and can be used for free to cover the up to 15 languages we have on the i18n site, but also we're often dealing with multiple languages on a given page for examples etc, which also ramps up the bandwidth when using webfonts.

What am i missing?