gmane.comp.web.css.general

Re: RE: [css-variables] Using $foo as the syntax for variables

Shane Stephens — 2012-05-25T05:35:34

I'll let Tab answer this more fully, but one advantage is laid out in my
response to your point #1.



Idiomatic usage for variables you want to have globally available would be
to put them in a :root { ... } rule. This then behaves identically to
< at >-rule approaches, but with the advantage that you can perform value
overriding in subtrees should you wish to.



Long-term, I am quite keen at looking at other abstractions for re-use and
modularity in CSS, but I am not keen to try and force every possible
approach into the same abstraction. Selector fragments have different
properties to value variables, and should be addressed separately, even if
we end up using similar syntax in the long run.

Additionally, it's not actually clear to me that you really want to have
very long selectors, given the performance problems that you'd incur.
Should we be encouraging this sort of thing?



Yes. This is an advantage. CSS doesn't have types, except at property
application time. We don't want to force a new type abstraction on CSS
developers just so they can use variables.

Remember that
p { background-color: 20px; }

is perfectly well handled by today's CSS engines.



I'm not sure what you're getting at here. Variable validation to a
particular property type is quite cacheable.



Indeed. Calling out late-validation as an issue in the current WD while
proposing it at the same time is an interesting move :)



I guess this is the core point at which the CSSWG feels differently. From
our perspective, variables are properties without direct effect on layout
or rendering. Properties get set on elements and inherited down the DOM, so
variables should too. We feel this approach is more consistent with the way
everything else in CSS works.



Given the attitude of the CSSWG towards variables defined at global scope
in the past, this isn't likely. It is certainly possible, however, should
you find any important use cases for variables in < at >-rules that can't be
solved simply by using the :root selector.

Cheers,
    -Shane

Re: RE: [css-variables] Using $foo as the syntax for variables

Sebastian Zartner — 2012-05-25T05:18:24

Sorry, I missed the earlier discussions about CSS variables. Could you explain which "very attractive features" that would be? Currently I just see the decent complexity this approach has.
Approaches using an < at >-rule would not allow to define a variable to be valid inside a specific element subtree but the variable values would still be inherited down the element tree. And their usage is a lot easier than the var- declaration inside style rules.

Disadvantages:
1. Variable's availability depends on element tree:
See example 6:
<one><two><three /></two></one>
one   { var-foo: 10px; }
two   { var-bar: calc(var(foo) + 10px); }
three { var-foo: calc(var(bar) + 10px); }

The variable "foo" is assigned another value inside <three>. If the order of <one>, <two>, <three> is reversed or <two> is used without being inside a <one> element, the "foo" variable is rendered invalid for it.
So while properties inside that rules will always be assigned to the element variables always depend on where the matched element is placed inside the tree, which can be quite confusing.
With an < at >-rule approach you wouldn't have this problem because variables would always be accessible. They would just be scoped by < at >media rules.

2. Can't be used for anything else than property values [1]:
Within an < at >-rule you could define all this, which helps for example when you have a very long selector. You will just put that selector into a variable and can then use it at any place you wish.

3. Variable values are not bound to any type of property:
Example 8:
:root { var-looks-valid: 20px; }
p { background-color: var(looks-valid); }

Example 9:
:root { var-not-a-color: 20px; }
p { background-color: red; }
p { background-color: var(not-a-color); }

My suggestions #2 and #3 bind a value to a specific property type, so a variable validation can already take place inside the < at >-rule and doesn't have to be done everytime the variable is used.

Admittedly allowing to define a variable value independently of a property is also an advantage since you can define e.g. a color value and use it in different properties. See my suggestion #1.


After all variables are something that doesn't affect the elements directly. So also logically they fit more into an < at >-rule.

Anyway, an < at >-rule defines a global variable definition while the current ED describes scoped variables. So both approaches do not exclude each other. So maybe both could find their place inside the spec.

[1] http://dev.w3.org/csswg/css-variables/#using-variables
[2] http://dev.w3.org/csswg/css-variables/#defining-variables
[3] http://lists.w3.org/Archives/Public/www-style/2012Apr/0814.html

Sebastian

Re: [css2.1][css3-fonts] keywords in unquoted font family names

John Daggett — 2012-05-25T04:42:12

Hi Gérard,

Why does your test require the default font to be set?  That doesn't
make much sense to me. Include a containing div and set its
font-family to "CSSTest FamilyName".

 <div id="verify">User agent's default font must be set to be "CSSTest FamilyName": 5678</div>

I also think you should include tests for 'foo, inherit' and 'inherit,
foo' and the same set of tests for the 'initial' keyword.

Cheers,

John Daggett

Re: [css3-fonts][cssom] Load events for webfonts?

Sebastian Zartner — 2012-05-25T03:54:03

Just to give another example where such events / API would be needed:

Firebug wants to highlight the used font(s) inside an element. For web fonts it fails because it displays the styles before the fonts are loaded:

http://code.google.com/p/fbug/issues/detail?id=2495

Sebastian

Re: [css3-fonts][cssom] Load events for webfonts?

Boris Zbarsky — 2012-05-25T01:36:24

That doesn't work in the not-uncommon case where the stylesheet is not 
same-origin with the page, no?

-Boris

Re: [css3-fonts][cssom] Load events for webfonts?

John Daggett — 2012-05-25T01:28:39

Tab Atkins Jr. wrote:


Er, search with "load event font-face" perhaps?

There have been a few discussions of this in the past but figuring out
the details of the event and what it does is tricky.  I agree
completely that something like this is needed.

The subject often comes up in the context of canvas elements, which
can draw text but have no way of knowing whether a given font was
loaded before the drawing takes place.  This needed in other contexts
also where fonts need to be dynamically loaded (in Gecko, the onload
handler will wait fonts needed for text on the page to finish loading
but Webkit fires the onload handler before loads are complete).

dbaron's comment summarizing the Gecko bug for this:


The tricky part of this is that < at >font-face fonts load on demand and
which font in a family is loaded is determined by the style matching
rules.  So if the author defines four < at >font-face rules for regular,
bold, italic and bold italic but only the italic face is needed,
that's the only one that will be loaded (modulo EOT font load behavior
in pre-IE9 versions of IE which is not lazy).

I think the two API's above may be the simplest to implement.  I think
the "all fonts loaded?" API should be associated with the document,
since fonts are attached to the document not to specific elements.

Specific proposals for this would be most welcome.

Sept 2011 thread:
http://lists.w3.org/Archives/Public/www-style/2011Sep/0012.html
http://lists.w3.org/Archives/Public/www-style/2011Sep/0014.html

July 2009 thread:
http://lists.w3.org/Archives/Public/www-style/2009Jul/0066.html
http://lists.w3.org/Archives/Public/www-style/2009Jul/0204.html

Beth Dakin and I also talked about this during TPAC in 2010 but no
proposals came out of that.

We have an open bug on this with lots of discussion:
https://bugzilla.mozilla.org/show_bug.cgi?id=471915

Re: [css3-fonts][cssom] Load events for webfonts?

Glenn Adams — 2012-05-25T01:05:06

+1

[css3-fonts][cssom] Load events for webfonts?

Tab Atkins Jr. — 2012-05-25T00:26:45

I couldn't find anything about this from a cursory search of the list.

Has any thought been given to exposing when fonts in < at >font-face are
loaded?  (Where "loaded" means "one of the sources is either
successfully downloaded and parsed, or is successfully found on the
local system, or all the sources fail".)

Our Docs team needs to know this information so it can do accurate
measurements of things, which are based on the metrics of the font
being used.  If a fallback font is being used because the main one
hasn't loaded yet, we'll do an initial sizing sweep, then watch for
the load using silly indirect means so we can redo all the sizing when
it loads and we swap out the fonts.

Right now, our technique is to render two spans positioned off-screen,
one with the fallback font and one with the < at >font-face font, and poll
the sizes on a timer until the second is a different size than the
first.  This is, of course, very silly.  It's also not reliable - if
the fallback font happens to produce a span the same width as the
loaded font, you'll never notice the load.  This may or may not be
okay for the overall sizing (depends on how close the metrics actually
are, and thus how much of a coincidence the same-size thing was), but
it's definitely bad that it means we have a timer running forever (or
until we hit our own timeout).

Other fairly advanced apps probably have similar needs.  Providing a
load event we can listen to instead of polling would be much less
fragile, more reliable, and cheaper for the user.

Preferably, it would be fired at the < at >font-face rule in the CSSOM, so
you don't have to go to any particular effort to figure out which font
it was.  If you do something more general like firing it at document,
you have to provide all the descriptors so you can distinguish
separate rules.

Thoughts?

~TJ

Re: [css2.1][css3-fonts] keywords in unquoted font family names

Gérard Talbot — 2012-05-24T23:43:29

Le Mer 23 mai 2012 21:13, John Daggett a écrit :

[snipped]



[snipped]





Tab and John,

I will submit

http://www.gtalbot.org/BrowserBugsSection/css21testsuite/font-family-rule-004a.xht

and

http://www.gtalbot.org/BrowserBugsSection/css21testsuite/font-52.xht

in a few days unless I hear feedback, objections against this from one of
you.

--------------

I have renamed the previous test as

http://www.gtalbot.org/BrowserBugsSection/css21testsuite/CSS3-font-family-rule-004a.xht

in case we need it later.


Gérard

RE: [css3-flexbox] flex-basis initial value should be 0px

Phil Cupp — 2012-05-24T23:34:21

On May 23, 2012 at 2:58 PM, fantasai wrote:

Min-content comes into play for a grid item any time its alignment is not stretch (stretch is the default alignment) as the grid item will be shrink-to-fit sized into its grid cell and then aligned.  Min-content also affects the size of the track (and therefore the size of any box that is stretch aligned over that track) when the track has a sizing function that uses one of the *-content keywords, e.g. minmax(min-content, 1fr) or auto which is equivalent to minmax(min-content, max-content).

If you have tracks sized to a certain length (or fraction or percentage on a non-auto sized grid element) and the grid item contained in a cell covering those tracks has stretch alignment, then the min-content size plays no part in determining the final size of the item's box.

Example:

<div style="display:grid;-ms-grid-columns:1fr;-ms-grid-rows:1fr;width:10px;height:10px">
    <div>I'm a grid item.  My box is ten pixels by ten pixels even if that causes my own contents to overflow my box.</div>
</div>

Hope that helps, Phil

[css-device-adapt] CSS Device Adaptation and legacy meta tags and doctypes

Kenneth Rohde Christiansen — 2012-05-24T23:02:57

Hi there,

TabAtkins told me that the CSS Device Adaption spec changed hands, so
I am adding the new editors to this thread.

Cheers,
Kenneth

Re: CSS Device Adaptation and legacy meta tags and doctypes

Kenneth Rohde Christiansen — 2012-05-24T23:00:46

Hi there,

TabAtkins told me that the CSS Device Adaption spec changed hands, so
I am adding the new editors to this thread.

Cheers,
Kenneth

On Mon, May 14, 2012 at 4:25 PM, John Mellor <johnme< at >chromium.org> wrote:

Re: [css3-flexbox] flex-basis initial value should be 0px

Ojan Vafai — 2012-05-24T22:47:34


It is. Like Tony, I also wasn't fully thinking through the problem to
realize that min-content doesn't need a full layout. It's often more
expensive, but it's not crazy more expensive the way that a second layout
is.



This satisfies me.

Re: [css3-flexbox] flex-basis initial value should be 0px

Tab Atkins Jr. — 2012-05-24T22:33:43

The min-content height of a block is the height of the content after
doing layout.  It's not like min-content width, where you can do a
much less expensive poll of your contents and take the max.



If dealing with the min-content restriction is indeed much cheaper
than a full layout in WebKit (I already know that it's cheaper in FF),
then yeah, I don't see any particular reason to default to 'auto' over
'0'.  They're equally safe, and neither seems to be obviously more
desirable as a default layout strategy.  Favoring the faster layout
system here seems like a win.

~TJ

Re: [css3-flexbox] flex-basis initial value should be 0px

Tony Chang — 2012-05-24T22:29:18


I started to measure this, then realized that computing the min-content
size doesn't require a full layout.  So having an implied minimum size for
a flex item isn't a problem.  I'm sorry for the confusion and ensuing
discussion caused by my mistake.  I got thrown off by this:

On Wed, May 23, 2012 at 11:23 AM, Tab Atkins Jr. <jackalmage< at >gmail.com>
 wrote:


Why does computing the min-height for a column flexbox require a full
layout?  In the case of column flexboxes, I don't think we have to do any
extra work because we can't end up smaller than the min-content (the height
is already the min).

That said, flex-basis: auto is about twice as slow as flex-basis: 0 (or any
other fixed value).  This is because before you can do the flex algorithm,
you need to compute the the basis (layout the child), then after you've run
the flex algorithm, you have to do a second layout at the computed width.

I would prefer that the initial value of flex-basis be 0.  As Tab mentioned
up thread, this won't cause overflow anymore than flex-basis: auto.

tony

[css3-images][css4-images] Replace 'dppx' with 'x'?

Tab Atkins Jr. — 2012-05-24T21:41:53

There's been a decent bit of feedback recently about the 'dppx'
resolution unit, since Responsive Images have become popular over in
HTML.  The feedback has pretty much all been negative about the name,
though.  It seems to be generally considered to be a difficult name to
read and even write (with a lot of 'ddpx' typos, even from people here
in the WG).

Apple's image-set() proposal, and HTML's new <img srcset> proposal,
both use a simple 'x' unit to denote the same thing.  What do we think
about doing the same thing?

I see two ways this could happen:

1. We modify the Images 3 CR.  In the absence of a CR errata
mechanism, this means another Last Call, though we could certainly
annotate the draft to make it clear that it's not a big deal, or
simply keep it low-key like we did with B&B recently.

2. We wait for Images 4 and add it, deprecating dppx along the way.
We can either invoke an explicit aliasing mechanism here, or just
define it identically and say that authors must not use dppx.

Thoughts?

~TJ

Re: [css3-transitions] colour space used for colour interpolations

Tab Atkins Jr. — 2012-05-24T20:47:57

Heh, who would ever want to transition in RGB?  It's infinitely worse. ^_^

Ultimately, what matters is what the system graphics libraries
support, or can be extended to support.  HSL is a pretty shitty
colorspace, but it's simple to work with, and way better than RGB for
most things.  If we can convince the implementors working on graphics
to do a better colorspace, awesome, but if we can't, falling back to
HSL is acceptable in my mind.

(The major problem with HSL, more than anything else, is that there's
no analog of "premultiplied" colors like RGBA has, so transitions
to/from 'transparent' are going to be ugly.  I don't think any of the
better colorspaces have a solution to this either.)

~TJ

Re: [css-variables] Using $foo as the syntax for variables

Brian Kardell — 2012-05-24T19:53:03

I would like to advocate that it is worth considering _not_ putting $
on the property side for assignment.  Currently:


    :root{  $bg: red;  }
    .blah{  background-color: $bg;  }

As I said earlier, I actually kind of like it as a reference mechanism
for the simple case for several reasons, not the least of which is
that it is actually a pretty standard metaphor used in languages and
templating languages that a whole lot of Web developers and designers
are familiar with. The flip side is, assignment usually uses a special
keyword.  Maybe that isn't the shortest syntax that's possible, but
it's familiar and not very cumbersome.  It also "feels" more like CSS.
 Let me explain...

Keep in mind, I'm not talking about how it is processed, or how the
browser handles it,  but now with CSS' modules you have something
like:

    [module]-[property]:   value;

and shorthands are are generally just:

    [module]:  [value...];

That's a nice, simple and _extremely_ easily teachable model.  If
there are exceptions, they are few, and I think Lea suggested recently
that it's best to document a rule and note the few exceptions going
forward.  Given all of this, I find:

    :root{  var-bg: red;  }
    .blah{  background-color: $bg;  }

in the same easy/teachable/conforming to the familiar categories as
the rest of CSS.  It lets you think of "var" as a module with user
definable properties, it's a lot like data-* which inspired a lot of
this.

It's just my opinion, but I'm curious what anyone has to say about it.

-Brian



On Thu, May 24, 2012 at 1:06 PM, Tab Atkins Jr. <jackalmage< at >gmail.com> wrote:

Re: [css3-flexbox] Bikeshed ALL the things

fantasai — 2012-05-24T19:00:15

As Tab noted, the start/end pair is well-established already,
so we won't change that to beginning/end (besides, we should
avoid 'ing' endings).

The idea of using prefixes to disambiguate is an interesting
one. I'm not sure it works so well with e.g. margin-inline-start,
or in cases where we think we only need one pair, but wind up
adding a second later (this has happened to float). But I'd
consider it.

This is my view:
   http://lists.w3.org/Archives/Public/www-style/2012May/0885.html
I'm mainly concerned about consistency across CSS as we add
more instances of logical vocabulary.

~fantasai

Re: [css3-flexbox] flex-basis initial value should be 0px

Brad Kemper — 2012-05-24T17:50:10


I don't think so. I think it is because of the 'tables are evil for layout' evangelism, and for the desire to have semantic markup, and avoid the table>tbody>tr>td nesting with tables inside of tables inside of tables inside of tables. The main complaints about 'display: table-cell' we're from people who misunderstood the 'tables are evil for layout' message, not from people who thought it was too slow. I've had to deal with styling other people's extremely table heavy markup, but I never noticed slow speed as a significant result of that (though I don't doubt it would have been somewhat faster otherwise, just not enough to notice).

Re: [css3-flexbox] order

fantasai — 2012-05-24T17:48:06

Speech doesn't read the visual box tree, it creates its own.
If speech needs to support flexbox, that's a new feature and
needs its own definition.

~fantasai