Discussion:
[css3-conditional] @supports rule
(too old to reply)
Dennis Heuer
2018-01-16 23:45:09 UTC
Permalink
Raw Message
Hello,

if I read well, the rule @supports is only taking single properties as
arguments. I'd like to see it support css version and spec names to
allow enframing the case more widely, like:

@supports css21 and (css3: text-decoration, compositing, transform) ...

This is a quite arbitrary example... Just a guess...

Regards,
---------------------------------------------------------------------
Dennis Heuer
***@verschwendbare-verweise.seinswende.de
Dennis Heuer
2018-01-17 00:04:09 UTC
Permalink
Raw Message
On Wed, 17 Jan 2018 00:45:09 +0100
Post by Dennis Heuer
Hello,
arguments. I'd like to see it support css version and spec names to
@supports css21 and (css3: text-decoration, compositing,
transform) ...
This is a quite arbitrary example... Just a guess...
Regards,
---------------------------------------------------------------------
Dennis Heuer
@supports (css3: spec:sub) ...

might be helpful if the spec covers too much. sub would be border,
background or the like...

Regards,
---------------------------------------------------------------------
Dennis Heuer
***@verschwendbare-verweise.seinswende.de
Dennis Heuer
2018-01-17 01:17:01 UTC
Permalink
Raw Message
On Wed, 17 Jan 2018 01:04:09 +0100
Post by Dennis Heuer
@supports css21 and (css3: text-decoration, compositing,
transform) ...
This is a quite arbitrary example... Just a guess...
This is answering the response. Sorry, lost that email already...

First, css _is_ versioned. There is css21, and we talk about proposals
for css3. Only, you can't version in css. That is sad, from my point of
view. However...

Second, I understand your position. But something made me think. When
it's only about cheating, how can you stop this at all? Who says that
the browser will not check different for @support rules? And even when a
browser parses a rule correctly, that does not mean that he displays
correctly. We can not make a standard against this. But we can make a
standard with interesting features that might be supported by the
browsers that win the hearts of the users. That's how I think.

However, no more burden to the poor human who has to type down all the
properties. Funnily that's what I'm doing right now for my selfbrewn
lesscss (lesserphp) 'toolkit'. It's total overload and targeted at
theme'ing my wiki. But it's fun and a silent wish for css. You can
check the below (arbitrary) example at:

http://leafo.net/lessphp/editor.html:


// less is not a programming language, causing redundancy

text-decoration-line(@value:@text-decoration-line) when not (@value=-)
{text-decoration-line: @value;}

text-decoration-style(@value:@text-decoration-style) when not (@value=-)
{text-decoration-style: @value;}

text-decoration-color(@value:@text-decoration-color) when not (@value=-)
{text-decoration-color: @value;}

text-decoration(@line: @text-decoration-line,
@style: @text-decoration-style,
@color: @text-decoration-color,
@base: @text-decoration)
{
caller() when not (@base = -){
text-decoration: @base;
} caller();
text-decoration-line(@line);
text-decoration-style(@style);
text-decoration-color(@color);
}

@fallbacks { // could be normalization or theme widget values in .ini
@text-decoration: - ;
@text-decoration-line: - ;
@text-decoration-style: wavy;
@text-decoration-color: blue;
} @fallbacks();


div {
//text-decoration(underline, , ,initial); should work but doesn't
text-decoration(@line: underline, @base: initial);
}

The result is:

div {
text-decoration: initial;
text-decoration-line: underline;
text-decoration-style: wavy;
text-decoration-color: blue;
}



Regards,
---------------------------------------------------------------------
Dennis Heuer
***@verschwendbare-verweise.seinswende.de

Tab Atkins Jr.
2018-01-17 00:12:16 UTC
Permalink
Raw Message
On Tue, Jan 16, 2018 at 3:45 PM, Dennis Heuer
Post by Dennis Heuer
Hello,
arguments. I'd like to see it support css version and spec names to
@supports css21 and (css3: text-decoration, compositing, transform) ...
This is a quite arbitrary example... Just a guess...
As previous emails have explained, CSS is not versioned.

As for providing an entire spec name, that's problematic for a few reasons.

1. Some spec names overlap with property names, like "transform".

2. Spec names are intended to be human-only; we didn't choose their
names with the intention to show up in APIs.

3. Most importantly, the @supports rule is very intentionally designed
to rely solely on existing parsing machinery, rather than
human-maintained lists. To evaluate a support condition, all a
browser has to do is feed the property+value to their CSS parser and
see if it parses or not. This system avoids the failure modes of
previous attempts at providing an "is this supported?" API, namely
that a human-maintained set of features is often out of date or
encourages lying. These problems made the legacy hasFeature() JS API
mostly useless, for example. Allowing an author to ask "is this
entire spec supported?" falls exactly into that failure mode.

~TJ
Loading...