Gabriele Romanato | 1 Oct 09:01 2008
Picon

[validator] the <at> profile at-rule

Many authors experience several problems in the use of the validator's URI syntax.
Instead of using the string &profile I propose the <at> profile at rule to be put at
the very beginning of a style sheet. The syntax of this rule is the same as the charset one.
Possible values: css1, css2, css2.1, css3. Example:

<at> profile "css3";

#nav li:last-child {border-right: none}

Gabriele Romanato

--
http://www.css-zibaldone.com/
http://www.css-zibaldone.com/test/ (English)
http://www.css-zibaldone.com/articles/ (English)
http://mimicry.css-zibaldone.com/   (Blog)

François REMY | 1 Oct 16:01 2008
Picon

Re: [Css Variables] Variable Declaration Blocks


> L. David Baron wrote:
>> Mike Wilson wrote:
>> > It would be great if you could expand a little on why having
>> > changeable variables breaks the cascading order?
>>
>> I expanded on it a bit in
>> http://lists.w3.org/Archives/Public/www-style/2008Aug/0169.html
>
> Ah, thanks. I did read it at the time but apparently I failed to
> make a mental note to come back to it, sorry about that.
> I'm inlining below to continue the discussion:
>
> On Fri, 22 Aug 2008 16:21:40 +0100 L. David Baron wrote:
>> If the complex variable can be changed later, I'm not
>> sure how to reflect in the CSS object model that there's a
>> declaration block a declaration like:
>>
>>  <at> define {
>>   complexVariable {
>>     color: blue;
>>   }
>> }
>>
>> p { var(complexVariable); color: green; }
>> q { color: purple; var(complexVariable); }
>>
>> such that p elements are green, q elements are blue, but if we
>> dynamically change complexVariable to no longer declare the color
>> property, q elements would change to purple.  (And consider
>> especially dynamic mutation of sheet.cssRules[i].style.color on the
>> p and q rules, which is already permitted.)
>
> If I understand you correctly here, your picture of how this would
> function is that the var(complexVariable) reference would inline
> all its properties right into p and q, resulting in the following
> view for the user code:
>
>  p { color: blue; color: green; }
>  q { color: purple; color: blue; }
>
> which indeed would break the one-value-per-property-per-declaration-
> block rule if we want to access both with CSSOM. (I guess this is
> the problem there has been talk about, and not the one I outlined
> in my previous mail to Dave Hyatt.)
>
> The way I have thought about this is that variable references would
> actually be exposed to CSSOM client code just like they are:
>
>  complexVariable { color: blue; }
>  p { <ref to complexVariable>; color: green; }
>  q { color: purple; <ref to complexVariable>; }
>
> When the user code calls sheet.cssRules[i].style.color it will always
> be the rule's own color property being addressed and there is only
> one value per property. (The resulting style on dependent elements
> will of course include stuff from variables though.)
> The variable itself is accessed through CSSOM like if it was a
> separate rule.
>
> References to complex variables could be exposed in many ways, from
> dedicated API all the way down to a simple "variables" property
> containing a white-space delimited list of variable names (like
> the "classes" property in HTML elements):
>
>  p { variables: complexVariable; color: green; }
>  q { color: purple; variables: complexVariable; }

I agree with you.
The complex variable should not be merged with the real selector.
But at this time, I think "variables:" is not as good as "imports:" or 
"extends:"

And if we look at a previously defined problem,

     <at> define {
        complex: {
            color: red;
        }
    }

should be replaced by

     <at> define complex {
            color: red;
    }

>
> I guess the variables could also be kept out of the property list
> in the CSSOM API. Something like the following could be possible:
>
>  p { color: green; }
>  and the corresponding
>  CSSStyleRule.variables.item(0) = "complexVariable"

+1

>
> That would lose the positional priority from your example where
> p's color wins over complexVariables's, but q doesn't, but maybe
> that is not an important point for variables. If it's not then
> we could f ex decide that all properties defined in a rule will
> win over assignments in a referenced variable (just like "style"
> wins over referenced classes in HTML elements).
>
> Did all this make sense, or maybe there are other things in this
> that I am missing and that cause further problems?
>
> Best regards
> Mike Wilson
>
> 

Andrew Fedoniouk | 1 Oct 18:46 2008

Re: [Css Variables] Variable Declaration Blocks


Why would people need "CSS variables" at all?

We've got a lot of discussion around them but I am failing to
see the forest behind those trees.

Could anyone clearly explain why "CSS variables" there at all:
1) What problems they are trying to solve, etc.?
2) Why they are variables and not constants?
3) Are there any requests from community for exactly variables?

Thanks in advance.

--

-- 
Andrew Fedoniouk.

http://terrainformatica.com

fantasai | 1 Oct 19:05 2008
Picon

Re: standardization of IE's conditional comments


Garrett Smith wrote:
> On Mon, Sep 29, 2008 at 10:26 AM, Garrett Smith <dhtmlkitchen <at> gmail.com> wrote:
>> On Sun, Sep 28, 2008 at 10:59 PM, Jens Meiert <jens <at> meiert.com> wrote:
> 
> 
>> The OP did not state where HTTP content negotiation or css media
>> queries failed him. Gabriele - What are you trying to accomplish that
>                  ^^^
> her.
> 
> My apologies.

Actually,  you were right the first time.

~fantasai

fantasai | 1 Oct 20:24 2008
Picon

[CSSWG] Minutes and Resolutions 2008-10-01


Summary:

   - Charter has been sent to AC for approval
   - RESOLVED: Add to css3-marquee Bert's note:
                 Note that the 'direction' property is often set by rules
                 in the UA style sheet based on mark-up in the document,
                 as recommended in CSS 2.1 [CSS21] section 9.10 ("Text
                 direction: the 'direction' and 'unicode-bidi' properties").
   - RESOLVED: Publish CSS3 Marquee as CR
   - Accepted to clarify spec that comments are not allowed inside url()
     syntax, pending MSFT's approval.
   - RESOLVED: Proposal accepted for CSS2.1 Issue 74
                 http://wiki.csswg.org/spec/css2.1#issue-74
   - For CSS2.1 Issue 72, need text that also says that widths of columns
     in fixed layout is undefined when table has extra columns after 1st row.
       http://wiki.csswg.org/spec/css2.1#issue-72
   - RESOLVED: For CSS2.1 Issue 76, proposed to rewrite 1st paragraph of
               http://www.w3.org/TR/CSS21/page.html#outside-page-box as
                 When formatting content in the page model, some content
                 may end up outside the *current* page box. For example,
                 an element whose 'white-space' property has the value
                 'pre' may generate a box that is wider than the page box.
                 *As another example*, when boxes are positioned absolutely
                 *or relatively*, they may end up in "inconvenient" locations.
                 For example, images may be placed on the edge of the page
                 box or 100,000 meters below the page box.
               (Changes emphasized.)
               http://wiki.csswg.org/spec/css2.1#issue-76
   - RESOLVED: For CSS2.1 Issue 77
                 http://wiki.csswg.org/spec/css2.1#issue-77
               accepted Saloni's proposal
                 http://lists.w3.org/Archives/Public/www-style/2008Sep/0233.html
               with the last sentence changed to
                 Parts of the fixed position box that are not visible in the
                 initial containing block will not print.
   - Added
       http://lists.w3.org/Archives/Public/www-style/2008Sep/0232.html
       http://lists.w3.org/Archives/Public/www-style/2008Sep/0232.html
     to TPAC agenda.

====== Full minutes below =====

Attendees:

   David Baron
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Peter Linss
   Saloni Mira Rai
   David Singer
   Jason Cranford Teague

<RRSAgent> logging to http://www.w3.org/2008/10/01-css-irc
<RRSAgent> http://www.w3.org/2008/10/01-css-minutes.html

Agenda
------

   Agenda: http://lists.w3.org/Archives/Member/w3c-css-wg/2008OctDec/0000.html
   Daniel: Any other items for agenda?
   Daniel: I tried to get agenda items from both mailing lists, let me know if I missed any
   Daniel: regrets from molly, jeffrey, mohamed

Charter
-------

   Daniel: Charter was sent by IJ to list of AC reps for approval and vote
   Daniel: In case they missed it, I suggest you ping your AC reps to let them know that the charter is up for approval
   Daniel: In the voter form, the AC rep needs to indicate intent or not to join WG
   Daniel: It's important, please don't miss it

CSS3 Marquee
------------
   <glazou> http://lists.w3.org/Archives/Member/w3c-css-wg/2008JulSep/0248.html
   Daniel: First issue is about potential change in 'direction' of marquee
   <glazou>     Note that the 'direction' property is often set by rules
   <glazou>     in the UA style sheet based on mark-up in the document, as
   <glazou>     recommended in CSS 2.1 [CSS21] section 9.10 ("Text direction:
   <glazou>     the 'direction' and 'unicode-bidi' properties").
   fantasai: works for me, I think we should add it
   RESOLVED: Accepted to add Bert's note
   Daniel: Question is shall we publish css3-marquee as CR.
   Daniel: Got 2 comments from i18n, above and one other, both are resolved.
   Daniel: Any objections to moving to CR?
   RESOLVED: Publish CSS3 Marquee as CR
   ACTION: Bert publish CSS3 Marquee as CR
   <Bert> (Publishing moratorium is 13 Oct - 27 Oct)

CSS2.1
------

   Daniel: Many recent comments about spec, mostly from Saloni
   Daniel: First one

   http://wiki.csswg.org/spec/css2.1#issue-73
   <glazou> http://lists.w3.org/Archives/Public/www-style/2008Sep/0198.html
   Peter: The more I think about it, the more I think we should not allow
          comments in URLs
   Peter: comment delimiters are valid URL syntax, and URLs have a special
          tokenization
   Peter: you're not in normal CSS rules
   Peter: There are places where you can determine whether it's a comment
          or part of URL
   Peter: other places where you can't
   <dbaron> I agree with Peter about how it should work.
   dbaron: Are there any browsers that don't do what you think we should do?
   Peter: I talked with zweinberg
   Peter: Opera does not allow comments within parentheses
   dbaron: I'm ok with the proposal given that
   Jason: I did a quick search, don't see anyone using it as a hack either
   Peter: IE7 and Gecko allow comments
   Daniel: So if proposal is accepted, there's no change for Opera, slight
           change for Mozilla and IE
   Daniel: David is ok with it
   Daniel: What about MS?
   dsinger: Anyone know about webkit?
   <Bert> Konqueror seems not to allow comments.
   ACTION: Saloni return to WG with response about whether proposal is
           acceptable
   <Bert> Webkit seems the same as Konqueror.
   dbaron: So my understanding is no change to the spec
   Daniel: We might need a note saying that it's explicitly forbidden
   Peter: There are various bits of text in the spec that talk about comments
   Peter: Saying that they're allowed between any tokens
   Peter: and URL is one token
   ACTION: Peter create note about how URL has its own syntax and parsing rules
   Peter: I also noticed that the grammar for URL leaves out a-z and 0-9
   dbaron: There might be a range in there that doesn't look like a range
   Peter: I didn't see one
   dbaron: *-~ is a range, and includes everything you mentioned

   http://wiki.csswg.org/spec/css2.1#issue-74
   <glazou> http://lists.w3.org/Archives/Public/www-style/2008Sep/0228.html
   fantasai: I am strongly in agreement with the proposal
   RESOLVED: Proposal accepted

   http://wiki.csswg.org/spec/css2.1#issue-72
   <glazou> http://lists.w3.org/Archives/Public/www-style/2008Sep/0152.html
   Saloni: With fixed table layout in CSS, if a row has more columns than
           the first row
   Saloni: The spec says you shouldn't render those columns, but the
           browsers actually do render those cells
   Saloni: I understand the value of fixed layout, I think it's important
   Saloni: So I propose relaxing the requirement in CSS2.1, and then clarify
           in CSS3 what exactly should happen
   dbaron: That would leave internal contradictions in the spec
   fantasai: we could say that if there are extra cells, rendering is undefined
   fantasai: or at least the widths of columns and the table are undefined
   <sylvaing> agrees with Elika+Saloni
   Saloni: So we'd be saying if you have fixed table layout, and extra cells,
           the layout is undefined
   ACTION: Saloni propose text for CSS2.1 Issue 75

   <glazou> http://lists.w3.org/Archives/Public/www-style/2008Sep/0153.html
   Saloni: That's resolved, we got an explanation of why this rule is in place

   http://wiki.csswg.org/spec/css2.1#issue-76
   <glazou> http://lists.w3.org/Archives/Public/www-style/2008Sep/0229.html
   <fantasai> When formatting content in the page model, some content may
              end up outside the *current* page box. For example, an element
              whose 'white-space' property has the value 'pre' may generate
              a box that is wider than the page box. Also, when boxes are
              positioned absolutely *or relatively*, they may end up in
              "inconvenient" locations. For example, images may be placed
              on the edge of the page box or 100,000 meters below the page
              box.
   Daniel: Change "Also" to "As another example"
   RESOLVED: Accepted above proposal

   http://wiki.csswg.org/spec/css2.1#issue-77
   <glazou> http://lists.w3.org/Archives/Public/www-style/2008Sep/0233.html
   Daniel: "Parts of the fixed position box that are not visible in the
            initial containing block will not print"
   RESOLVED: Proposal accepted with above change.

   <glazou> http://lists.w3.org/Archives/Public/www-style/2008Sep/0232.html
   Some discussion
   Added to agenda for TPAC

   http://lists.w3.org/Archives/Public/www-style/2008Sep/0230.html
   fantasai: Jason, I think we'll want your feedback on this issue
   <Bert> (Prince shows a fourth option: the box is 500px high on *both*
           pages. I don't particularly like that solution.)
   discussion ...
   fantasai: So I think the distance between the bottom of the last
             content on the page that fit and the bottom of the page
             should not count as part of the used height
   fantasai: So in this case you would still have used height left
             over that you use on the next page
   fantasai: Whether the background prints in that space (between the
             page break and the bottom of the page) is a separate issue
   Daniel: Postponed to TPAC
   fantasai: I think we need a web designer involved in this discussion
   Jason: I should be able to be online 9-5 EST during TPAC

Media Queries
-------------

   dbaron: Given that anne isn't here, we should postpone that one
   <glazou> postponed

Meeting closed.

fantasai | 1 Oct 23:28 2008
Picon

[CSS21] Table Column Group Widths


I was reviewing Gabriele's tests, this one in particular:
   http://www.css-zibaldone.com/test/tables/table-reflow-021.xht

CSS2.1 leaves the influence of width on column groups and columns
undefined for auto-width tables. But it also leaves undefined
whether the width on a column group is interpreted as per-{column
inside the column group} or per-{column-group box}. Even assuming
that table columns always get the width they specify (which should
be true if the cells are all empty), the rendering of this testcase
is undefined.

The only place width on columns is defined is here:
   http://www.w3.org/TR/CSS21/tables.html#columns

It says

   #  The following properties apply to column and column-group
   #  elements:
   # ...
   # 'width'
   #    The 'width' property gives the minimum width for the column.

I propose changing that to

   |    The 'width' property gives the minimum width for each column
   |    associated with the element.

~fantasai

Andrew Fedoniouk | 2 Oct 01:30 2008

Re: [Css Variables] Variable Declaration Blocks


David Smith wrote:
> [skiped]
> In a number of cases, the keywords in question refer to persistent 
> attributes of a conversation such as the url of an icon representing 
> the person you're talking to, or their name, rather than per-message 
> attributes like the exact text sent. When these persistent attributes 
> change, Adium has to traverse the whole DOM looking for places where 
> they were used and updating to the new value, which is definitely less 
> than ideal. CSS variables would make this completely trivial, as well 
> as significantly faster. Instead of something like <div 
> class="message"><img 
> src="%%userIcon%%">%%displayName%%%%message%%</div> we would have <div 
> class="message %%senderID%%">%%message%%</div> and use content() and 
> background-image with variables to insert the persistent name and 
> icon. Updating when the name or icon changed would then be a simple 
> matter of setting a new value via the CSSOM.
> [skiped]
So you have dynamically generated content like this:
<div class="message %%senderID%%">....</div>

While adding new sender you need to add single rule like:

div.that-sender-id { background-image:url(that-sender-avatar.gif); ... }

by using CSSOM.

You do not need CSS variables for that until I missed something in your 
task definition ...

-- 
Andrew Fedoniouk.

http://terrainformatica.com

>
>                                 David Smith
>
> On Oct 1, 2008, at 9:46 AM, Andrew Fedoniouk wrote:
>
>>
>> Why would people need "CSS variables" at all?
>>
>> We've got a lot of discussion around them but I am failing to
>> see the forest behind those trees.
>>
>> Could anyone clearly explain why "CSS variables" there at all:
>> 1) What problems they are trying to solve, etc.?
>> 2) Why they are variables and not constants?
>> 3) Are there any requests from community for exactly variables?
>>
>> Thanks in advance.
>>
>> -- 
>> Andrew Fedoniouk.
>>
>> http://terrainformatica.com
>>
>
>

fantasai | 2 Oct 02:17 2008
Picon

Re: [validator] the <at> profile at-rule


Gabriele Romanato wrote:
> Many authors experience several problems in the use of the validator's URI syntax.
> Instead of using the string &profile I propose the  <at> profile at rule to be put at
> the very beginning of a style sheet. The syntax of this rule is the same as the charset one.
> Possible values: css1, css2, css2.1, css3. Example:
> 
>  <at> profile "css3";
> 
> #nav li:last-child {border-right: none}

Hi Gabriele,

The CSSWG discussed having version identifiers in the style sheet
awhile ago and concluded not to do this. Instead, the validator
should validate against all properties in CR or higher, and if
someone wanted a specific profile (like CSS2.1 only, or Mobile
Profile only) then they could select that profile.

We also suggested that the validator could have a schema format
for listing properties valid in a particular format. That way the
CSS authoring community could come up with various profiles for
"safe" properties based on what browsers X, Y, Z support.

~fantasai

David Smith | 2 Oct 01:14 2008
Picon

Re: [Css Variables] Variable Declaration Blocks


I've been watching the CSS variables proposal with quite a bit of  
interest, since it would be extremely helpful for what I'm doing. I  
work on Adium (adiumx.com) a popular open source instant messaging  
program, which uses HTML/CSS/JS for displaying messages. Currently  
this works by having message style authors provide HTML templates with  
special keywords; when a message is sent or received, the template is  
copied, the keywords filled in with the current values, and the  
resulting html string is sent to WebKit using the Objective-C DOM  
interface (createContextualFragment specifically). You can see  
examples of message styles created by the community here: http://adiumxtras.com/index.php?a=search&cat_id=5

In a number of cases, the keywords in question refer to persistent  
attributes of a conversation such as the url of an icon representing  
the person you're talking to, or their name, rather than per-message  
attributes like the exact text sent. When these persistent attributes  
change, Adium has to traverse the whole DOM looking for places where  
they were used and updating to the new value, which is definitely less  
than ideal. CSS variables would make this completely trivial, as well  
as significantly faster. Instead of something like <div  
class="message"><img src="%%userIcon%%">%%displayName%%%%message%%</ 
div> we would have <div class="message %%senderID%%">%%message%%</div>  
and use content() and background-image with variables to insert the  
persistent name and icon. Updating when the name or icon changed would  
then be a simple matter of setting a new value via the CSSOM.

Tim Hatcher, the developer of http://colloquy.info/, has expressed  
interest as well for very similar reasons.

I realize this may be a bit out of scope for CSS's intended uses, but  
I think the use I've described would very likely have parallels in  
many web applications (gmail seems like an obvious one, given its  
similarities to a chat program).

								David Smith

On Oct 1, 2008, at 9:46 AM, Andrew Fedoniouk wrote:

>
> Why would people need "CSS variables" at all?
>
> We've got a lot of discussion around them but I am failing to
> see the forest behind those trees.
>
> Could anyone clearly explain why "CSS variables" there at all:
> 1) What problems they are trying to solve, etc.?
> 2) Why they are variables and not constants?
> 3) Are there any requests from community for exactly variables?
>
> Thanks in advance.
>
> -- 
> Andrew Fedoniouk.
>
> http://terrainformatica.com
>

David Smith | 3 Oct 07:07 2008
Picon

Re: [Css Variables] Variable Declaration Blocks


That's an excellent point, actually. It's perhaps not quite as elegant  
but it does have the distinct advantage of working right now. A few  
lines of JS wrapping it should make it simple to update rules on the  
fly as well. I'll give it a shot and see how it works out in practice;  
thanks for the suggestion!

					David

On Oct 1, 2008, at 4:30 PM, Andrew Fedoniouk wrote:

>
> David Smith wrote:
>> [skiped]
>> In a number of cases, the keywords in question refer to persistent  
>> attributes of a conversation such as the url of an icon  
>> representing the person you're talking to, or their name, rather  
>> than per-message attributes like the exact text sent. When these  
>> persistent attributes change, Adium has to traverse the whole DOM  
>> looking for places where they were used and updating to the new  
>> value, which is definitely less than ideal. CSS variables would  
>> make this completely trivial, as well as significantly faster.  
>> Instead of something like <div class="message"><img src="%%userIcon% 
>> %">%%displayName%%%%message%%</div> we would have <div  
>> class="message %%senderID%%">%%message%%</div> and use content()  
>> and background-image with variables to insert the persistent name  
>> and icon. Updating when the name or icon changed would then be a  
>> simple matter of setting a new value via the CSSOM.
>> [skiped]
> So you have dynamically generated content like this:
> <div class="message %%senderID%%">....</div>
>
> While adding new sender you need to add single rule like:
>
> div.that-sender-id { background-image:url(that-sender- 
> avatar.gif); ... }
>
> by using CSSOM.
>
> You do not need CSS variables for that until I missed something in  
> your task definition ...
>
> -- 
> Andrew Fedoniouk.
>
> http://terrainformatica.com
>
>
>>
>>                                David Smith
>>
>> On Oct 1, 2008, at 9:46 AM, Andrew Fedoniouk wrote:
>>
>>>
>>> Why would people need "CSS variables" at all?
>>>
>>> We've got a lot of discussion around them but I am failing to
>>> see the forest behind those trees.
>>>
>>> Could anyone clearly explain why "CSS variables" there at all:
>>> 1) What problems they are trying to solve, etc.?
>>> 2) Why they are variables and not constants?
>>> 3) Are there any requests from community for exactly variables?
>>>
>>> Thanks in advance.
>>>
>>> -- 
>>> Andrew Fedoniouk.
>>>
>>> http://terrainformatica.com
>>>
>>
>>
>


Gmane