gmane.comp.web.css.general

Re: [CSSOM-view] Support centering an element when scrolling into view.

Thaddee Tyl — 2012-05-26T05:12:40

In the process of specifying what I had in mind, I made the start of a polyfill.
It helped me identify another shortcoming of what I had done, namely having
a default `horizontal` property set to 0.0.

The code for the polyfill is available at
<http://jsbin.com/3/ilecok/5/edit?javascript>.

The WebIDL corresponding to this proposal is the following:

   partial interface Element {
     void scrollIntoView(ScrollPosition options);
   };

   dictionary ScrollPosition {
     float horizontal = 0.5;
     float vertical = 0.5;
     boolean evenIfViewed = false;
   };

This time, `horizontal` and `vertical` are meant as percentages of
the viewport width minus the offsetWidth of the element, and
the viewport height minus the offsetHeight of the element,
respectively.

This way, the element goes from having its top edge aligned with
the top edge of the viewport, to having its bottom edge aligned with
the bottom edge of the viewport, when changing `vertical` from 0 to 1.

Something else that I have uncovered from a r

Re: [css3-flexbox] flex-align:stretch on absolutely positioned items WAS: Changing abspos placeholders to atomic inlines

Tab Atkins Jr. — 2012-05-26T04:06:13

It should have an effect equivalent to align-self:start.  Remember
that it only stretches the placeholder, and abspos static position
only cares about the top-left (or top-right in rtl) of the
placeholder.

~TJ

[css3-flexbox] flex-align:stretch on absolutely positioned items WAS: Changing abspos placeholders to atomic inlines

Ojan Vafai — 2012-05-26T03:54:57



It's not clear to me with this change (or with the current spec text) what
should happen with flex-align/align-items: stretch on absolutely positioned
flex items. WebKit's current implementation happens to ignore stretch, but
that's not intentional. I can't really think of use-cases for wanting to
stretch absolutely positioned items, except if you're trying to overlay one
item on top of the other.

Ojan

Re: [css-variables] allowed syntax of variable values (was Re: status ?)

Tab Atkins Jr. — 2012-05-26T00:18:37

Ah, I see the confusion.  When I was referring to the DIMENSION token,
I meant the one in Chapter 4. The only Appendix G reference I was
making was for the "function" production.

But anyway, that's all gone now.

~TJ

Re: [css-variables] allowed syntax of variable values (was Re: status ?)

L. David Baron — 2012-05-25T23:11:34

Er, oh.  Actually, the DIMENSION token covers all units *except*
those that are in CSS2.1, which are covered by the EMS, EXS, LENGTH,
ANGLE, TIME, and FREQ tokens.

That said, Appendix G is designed to be a description of what syntax
is legal in CSS 2.1 and not designed to be a description of how to
parse CSS.  I still don't think it's a good idea to use it as part
of a spec for how CSS should be parsed.


Thanks.

-David

Re: [css3-lists] Counter style "hyphen" replaced with "dash"

Tab Atkins Jr. — 2012-05-25T23:06:23

Heh, I was confused by your references to "WD 7" and "WD 24".  Those
were published on Nov 7 and May 24, respectively.  ^_^

I don't recall any specific reason why I went with U+2014 instead of
U+2013.  It's possible that was a typo, since generally I just chose
one of the given example glyphs.

I changed the name on purpose, because if it was being represented by
a dash glyph, I thought it should be called 'dash'.  As far as I know,
no one implemented the 'hyphen' value.

~TJ

Re: [css-variables] allowed syntax of variable values (was Re: status ?)

Tab Atkins Jr. — 2012-05-25T22:55:56

Hm?  No, the DIMENSION token covers *all* possible units.



I've gone ahead and done so, but cleaned it up a little with more
explanatory text:

The <dfn id='value-type'><var>&lt;value></var></dfn> type used in the
syntax above is defined as
anything matching the "value" production in <a
href="http://www.w3.org/TR/CSS2/syndata.html#tokenization">CSS 2.1
Chapter 4.1</a> [[!CSS21]].
This puts almost no restrictions on what kinds of values you can store
in variables.
Obviously, any valid property value
or component of a property
is allowed.
Additionally, this allows things that aren't yet valid CSS,
like unknown keywords or functions,
blocks,
at-rules,
and other kinds of custom micro-syntaxes like what's allowed in calc().
There <em>are</em> still rules, however;
for example,
unbalanced parentheses are invalid.

~TJ

Re: [css-variables] status ?

Brian Kardell — 2012-05-25T22:40:57

The proposal on the table does not use var at all anymore, it uses $ on
both sides.  I have started a seperate thread on this if you want to
comment on this I suggest pulling it to there.
 On May 25, 2012 6:31 PM, "Peter Sorotokin" <psorotok< at >adobe.com> wrote:

RE: [css-variables] status ?

Sylvain Galineau — 2012-05-25T22:39:25

[Peter Sorotokin:]

The current grammar does not allow for spaces on the property side of the declaration.

We have unambiguously established that there is no proposal that will not be ugly to someone...

Re: [css-variables] status ?

Peter Sorotokin — 2012-05-25T22:28:27

Perhaps, a naïve question, but would not it be possible to do define
syntax as var foo instead of var-foo?

.container {
    var foo: 20px;
}

I guess I just like sh better than perl ;-)

I think var-foo is really ugly.

Peter

On 5/25/12 9:38 AM, "Tab Atkins Jr." <jackalmage< at >gmail.com> wrote:

Re: [css3-syntax] Preference for parser speccing?

Tab Atkins Jr. — 2012-05-25T22:23:34

On Fri, May 25, 2012 at 3:14 PM, Sylvain Galineau
<sylvaing< at >microsoft.com> wrote:

Tokens are easy - the tokenizer is already done in Syntax.  The
question is what to do with the parsing step, which turns tokens into
actual CSS structures and values.

HTML, for example, is defined with the tokenizing interleaved with the
parsing.  This is necessary for HTML, because some tags change the
tokenizing rules - if you see a <script>, you stop parsing like HTML
and instead just parse everything as text until you see the </script>,
because what's betweent hose tags simply isn't HTML, and you don't
want to risk screwing it up by parsing as HTML.

CSS *does* technically have this in one circumstance - the an+b syntax
of all the :nth-*() pseudos doesn't directly correspond to the tokens
of CSS.  However, it's possible to solve this by "reversing" the
tokens into something more meaningful, so you don't technically have
to switch contexts.

So the question is simply, as someone implementing or maintaining a
parser, which

RE: [css3-syntax] Preference for parser speccing?

Sylvain Galineau — 2012-05-25T22:14:34

[Tab Atkins Jr.:]
Not sure what you're asking. I think I'd rather implement a parsing algorithm
based on a clear and unambiguous definition of what the tokens actually are. 
Recent threads suggest the latter may need some polishing?

[css3-syntax] Preference for parser speccing?

Tab Atkins Jr. — 2012-05-25T22:08:43

This is just a general preference question for implementors.

When I pick up Syntax again, would it be better for me to write the
parsing section as if it the tokenizing was already completely done,
or interleaved with the tokenizing like the HTML parser is?  What
would be more useful?  I can do either, but I'd rather not have to
switch partway through, or even after I'm totally done.

~TJ

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

Tab Atkins Jr. — 2012-05-25T21:52:00

On Fri, May 25, 2012 at 2:26 PM, Christoph Päper
<christoph.paeper< at >crissov.de> wrote:

I have no idea what you are talking about.  "dpi" is a simple and
easy-to-understand unit.



Dude, you're arguing that "dpi" is a dumb unit.  I pointed out that
it's used plenty in real life, and people seem okay with it, thus your
premise is at least blunted, if not completely refuted.  There's
nothing wrong with "dpi", and there's nothing theoretically wrong with
a "dppx" unit.

This thread is solely about the naming of the unit.

~TJ

Re: [css-variables] $ for declaration? (not a variable on the left)

Tab Atkins Jr. — 2012-05-25T21:46:38

Because then it's nice and easy to see the relationship, and because,
in general, languages use the same syntax for setting and using
variables.

~TJ

Re: [css-variables] $ for declaration? (not a variable on the left)

Chris Eppstein — 2012-05-25T21:31:09

It really comes down to whether you conceive of $ as being a separate
concept from the variable. If you conceive of $ as a kind of escape that
indicates the next token is a variable name to be read, then $ is really
nothing more than a function that doesn't need parens. If instead you see $
as part of the variable name, then it makes sense for $ to always be
coupled whenever a variable is referenced.

It's my sense that people don't see $ as an escape, they see it a part of
the name.

Chris

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

Christoph Päper — 2012-05-25T21:26:57

Tab Atkins Jr.:

Everyone already knows it’s a silly unit (and an even sillier symbol/abbreviation). Its only “benefit” is that it makes random numbers bigger when better.

Just because it’s still used elsewhere – often in a confusing, misleading or incorrect way, too – doesn’t mean it’s a good idea to use it in CSS verbatim. I wouldn’t prefer the ‘calc()’ and “<number> /” variants I presented over a simple <length> one, but they’re at least more CSSy than the additional <resolution> unit type.


No, they shouldn’t have. They should measure sizes and distances like they know how.


You know, back when ‘dpi’ was introduced into CSS/MQ and ‘dpcm’ was invented specifically for it, some people including me tried to convince the WG that this was a bad idea, e.g. <http://lists.w3.org/Archives/Public/www-style/2006Aug/0204.html>.

Now you get negative feedback on ‘dppx’ which was modeled after the ill-advised ‘dpi’, except that it didn’t lose the second letter of the

[css-variables] $ for declaration? (not a variable on the left)

Brian Kardell — 2012-05-25T21:22:18

Apologies if this is dense...  I'm just wondering if some can explain
why having usage and reference match is desirable?  Tab has said
several times that he wanted it to match and some other at w3c did
too... Ok, I can respect that I, but can someone explain why it is
desirable?  It's non-obvious to me.

Several people (myself included) have raised all kinds of contentions,
some debated and deemed invalid and some not.  I posted some thoughts
advocating why not [1] but that thread quickly went downhill as $ on
the left making some people assume that either: a) that was a variable
reference (it wasn't) or b) not being able to have a variable
reference on the left was a bad idea (I think it isn't) and therefore
an argument against $ for declaration (I don't think it is, but the
confusion that ensued might be).

I'm definitely not saying it is _wrong_ or anything, just that I can
only reasons that it doesn't seem desirable right now... Can someone
share the reasons it is?


- Brian

[1] - http://lists.w3.org/Ar

Re: [css-variables] allowed syntax of variable values (was Re: status ?)

L. David Baron — 2012-05-25T20:51:03

I don't think we should add normative references to the informative
Appendix G.  I'd also note that this forbids the use of any new
units in the values of variables.


I'd consider it an improvement to change the "Values:" line back to
matching the part of the prose that says "The valid possible
values...".

-David

RE: [css-variables] status ?

Sylvain Galineau — 2012-05-25T20:50:50



This is off-topic. Compressing stylesheets when gzip is not available or
compensating for the peculiarities of a given HTTP stack is out of scope.

This is off-topic. Local 'preprocessing' is out of scope.

Re: [css-variables] status ?

Daniel Glazman — 2012-05-25T20:48:27

Le 25/05/12 22:41, Marat Tanalin | tanalin.com a écrit :


Like it or not, this is the scope of this proposal and we're not going
to go beyond it in the near future. Tab gave very good reasons for that.
I already asked you once to stop polluting this thread with off-topic
stuff, I suggest you stop _now_ or face a ban from this mailing-list.
The noise/signal ratio of this thread is just not acceptable.

</Daniel>
--
W3C CSS Working Group, Co-chair