Tab Atkins Jr. | 28 Jul 18:01 2014
Picon

Re: [css3-background] PFWG input on focus ring

On Fri, Jul 25, 2014 at 1:56 PM, Antony Kennedy <booshtukka <at> me.com> wrote:
>> On 25 Jul 2014, at 12:14, fantasai <fantasai.lists <at> inkedblade.net> wrote:
>> On 07/25/2014 07:30 PM, Tab Atkins Jr. wrote:
>>> On Fri, Jul 25, 2014 at 11:21 AM, Boris Zbarsky <bzbarsky <at> mit.edu> wrote:
>>>> On 7/25/14, 2:08 PM, Tab Atkins Jr. wrote:
>>>>> There is not. It has to either be marked !important in the UA style
>>>>> sheet by the UA, or duplicated in the user style sheet and marked
>>>>> !important.
>>>>
>>>> That said, if we did have a "default" value which meant "cascaded UA-level
>>>> value" in user sheets and "cascaded UA+user level value" in author sheets),
>>>> and the default focus ring were in fact a UA-level value, then doing
>>>> "default !important" in a user sheet would in fact work.
>>>
>>> I thought the only reason we didn't have that was implementation
>>> concerns? If people are down with it, I can add that easily.
>>
>> s/add/re-add/ ;)
>>
>> http://www.w3.org/TR/2013/WD-css3-cascade-20130103/#default
>
> For my use case, I would like to have a single user stylesheet that states e.g.
>
> :focus {outline: default !important;}
>
> Which maintains the author defined focus outline, and stops authors from overriding it. This seems like
it would meet this requirement?

Assuming you meant "UA-defined focus outline", then yes, that would do
what you want.
(Continue reading)

Brad Kemper | 27 Jul 17:26 2014
Picon

Re: [css-color-4] Renaming gray()


> On Jul 23, 2014, at 4:11 PM, "Jan Tosovsky" <j.tosovsky <at> email.cz> wrote:
> 
>> On 2014-07-23 Lea Verou wrote:
>> The gray() functional notation [1] is a great idea for specifying
>> desaturated colors with varying degrees of transparency in a concise
>> and
>> readable way. However, I’m not sure about the naming. Right now, the
>> named color `gray` corresponds to gray(50%). gray(0%) is black and
>> gray(100%) is white.
> 
> Some XSL-FO formatters use 'grayscale' psedo profile for this:
> http://mediawiki.renderx.com/index.php/XEP_User_Guide/Appendix_A_XSL-FO_Conformance#Color_Specifiers
> 
> But I take it rather as a syntactic sugar for CMYK: 0,0,0,blac(K).

I prefer black() to gray(), so it is a percentage of how black it is. This jives with my experience in the print
industry, where, while working with one-color spot printing, specifying a shade of the color (most often
of black), we did not gave under color removal or grayscale replacement to deal with. It was just a line
screen representing a percentage of how dark (how solid, really, since you could print in some other spot
color like yellow once you put it on the press) it should be. You had to deal with dot gain that depended on
what kind of paper you printed on, but I don't think that's relevant here.  

My point is that black() should not be treated the same as the K in CMYK after a non-naive conversion from RGB.
Black(100%) should be treated the same as rgb(0,0,0). 

> However, if I understand correctly, CSS gray is sRGB based and hence potentially problematic for
printing when transformed to device profiles. 
> 
> I like the approach of pseudo Gray/CMYK profiles as they allow me defining exact values which are
(Continue reading)

Lea Verou | 27 Jul 01:21 2014

[css-ui] Resize factor?

According to css-ui [1]:
When an element is resized by the user, the user agent keeps track of a resize factor (which is initially 1.0) for the width and height, which it then applies to the computed width and height as part of determining the used width and height. The element's contents (and surroundings) are reformatted as necessary.
and:
With regard to interactivity and the Document Object Model (DOM), the resize factor on an element lasts the lifetime of the element, however, if the ‘resize’ property itself is altered (e.g. via pseudo-class change or via DOM manipulation), then the resize factor is reset to 1.0.

So, if I’m reading this right, according to spec the resize factor is only reset if the resize property is dynamically altered. What happens then if width and height are dynamically altered? If the resize factor doesn’t reset, then the author gets completely different dimensions than the ones they used, for no obvious reason. It seems very confusing. 
(Although, none of the browsers I’ve tested seem to actually implement the resize factor anyway. They just modify width/height inline...)


Lea Verou  http://lea.verou.me   <at> leaverou







Brad Kemper | 26 Jul 21:18 2014
Picon

Re: Ambiguous hyphenation cases with

On Jul 22, 2014, at 2:17 PM, Kess Vargavind <vargavind <at> gmail.com> wrote:
> 
> That is, do like Icelandic and write food thief as <mattjuv> and carpet thief as <matttjuv>. Then there is
no trouble hyphenating.

How about if anyone who steals a carpet in Sweden is just forced to eat it as punishment. Then, carpet=food.
Problem solved!

Koji Ishii | 26 Jul 20:53 2014
Picon

[css-text] Add text-justify: inter-character back for Korean?

First, because this is very easy to confuse, allow me to clarify that this is a different topic from another
one on this list on justification algorithm. Another one is about an algorithm when lang is unknown. This
is about when lang=ko (Korean).

I’d like to propose to add text-justify: inter-character back. We removed this because at that point we
assumed that lang tag can cover all the cases inter-character would do, but the feedbacks from Korean
community[1][2] indicates the need for inter-character.

There are 3 types of Korean documents:
1. Ideographic only, ancient documents (may sometimes contain some hangul characters.)
2. Mostly Hangul, a few to some ideographic characters per a paragraph or a page.
3. All Hangul, no ideographic characters.

and the ratio of these documents are 1:20:80 or 10:20:70 (vary by people.)

With this in mind, we have 4 options for documents with lang=ko:
1. Make both Hangul and ideographic expandable if lang=ko. Authors have to add "text-justify:
inter-word” to 90-99% of documents (#2 and #3.)
2. Make both Hangul and ideographic non-expandable if lang=ko. #1 documents cannot be justified unless we
add inter-character back.
3. Make both Hangul and ideographic non-expandable if lang=ko. Tag #1 documents as “zh”.
4. Make Hangul non-expandable and ideographic expandable if lang=ko. Logically it’s strange to handle
Hangul and ideographic differently, but authors don’t have to add text-justify to 80% of documents (#1
and #3). 20% (#2) needs to add text-justify: inter-word.

Option 3 is very wrong, and disliked by the Korean community[2]. Option 1 is hard to take because it’s
likely to break a lot of existing documents on the web.

Both option 2 and 4 are technically possible, but to me, option 2 makes the most sense, and that option
requires inter-character.

Thoughts?

[1] http://lists.w3.org/Archives/Public/public-i18n-cjk/2014JulSep/0003.html
[2] http://lists.w3.org/Archives/Public/public-i18n-cjk/2014JulSep/att-0007/00-part

/koji

fantasai | 25 Jul 21:12 2014
Picon

Auto margins and shrinkwrapping [css-flexbox][css-grid][css-writing-modes]

(This is mostly a note to myself.)

Issue is wrt auto margins. Note: Margins default to zero.

For auto-sized items, a block-level block will fill its containing
block in the inline dimension. Setting margins to auto has no effect,
it's just like having zero margins. If you make the block smaller
than the containing block by setting an explicit width (or turning
it into a table), then it can be aligned with auto margins.

In flex and grid layout, if you have at least one auto margin, the
item shrinkwraps. Therefore, if its content is smaller than the
container, it can be margin-aligned.

I can't remember what we do with block-level grid and flex containers.
I think we should make them shrinkwrap if either margin is zero,
because that would be useful and make sense and the current behavior
is easy to get by *not doing anything* and getting the default margins
of zero.

This also shows up in orthogonal flows. Currently trying to unravel
that as well, and came to this conclusion, that they should shrinkwrap
if a margin is auto and fill-available otherwise.

~fantasai

Tab Atkins Jr. | 25 Jul 20:08 2014
Picon

Re: [css3-background] PFWG input on focus ring

On Thu, Jul 24, 2014 at 3:43 PM, Antony Kennedy <booshtukka <at> me.com> wrote:
>> On 23 Jul 2014, at 15:14, fantasai <fantasai.lists <at> inkedblade.net> wrote:
>> On 07/23/2014 06:26 PM, Antony Kennedy wrote:
>>>> A user can disable such modifications by restricting it via !important
>>>> rules in the user style sheet (or an equivalent UI control) just like
>>>> disabling author-specified colors and fonts.
>>>
>>> A user can set their own outline with !important, but out of interest,
>>> is there a way for them to stop the author overriding browser defaults?
>>
>> Yes. From CSS’s perspective, the browser defaults are represented
>> in the cascade as user-level style rules. So making those rules
>> !important (or in any case having them enter the cascade at the
>> user !important level) will "stop the author overriding browser
>> defaults".
>>
>> This is how we represent all such preferences, such as default
>> colors and fonts.
>
> Sure, but perhaps I am misunderstanding here.
>
> If I am writing my own user stylesheet, and I want to say "do not allow the author to change the focus outline
from the browser defaults" is there a way I can do that without duplicating the browser defaults in my user stylesheet?
>
> I understand the vendor could add !important, or I could write my own rules, but I am interested in knowing
if there is a way to mark certain rules as immutable, even if the vendor has not done this themselves.

There is not. It has to either be marked !important in the UA style
sheet by the UA, or duplicated in the user style sheet and marked
!important.

~TJ

Tab Atkins Jr. | 25 Jul 20:02 2014
Picon

Re: [css-syntax] Possible error in 4.3.4: Consume an ident-like token.

On Fri, Jul 25, 2014 at 4:35 AM, Ezequiel Rodriguez <ezequiel <at> yahoo.com> wrote:
> Context: http://dev.w3.org/csswg/css-syntax/#consume-an-ident-like-token
>
> In the third paragraph, it states:
>
>     ... If the next input token is U+0022 QUOTATION MARK (") or U+0027
> APOSTROPHE ('),
>     reconsume the current input code point, then create a <function-token>
> with its value set to the returned string and return it.
>
> At the point in time the above statement is executed, the current input code
> point is U+0028 LEFT PARENTHESIS ((). If we reconsume the current input code
> point, as instructed, the next token in the stream would then be a
> <delim-token> with the value of U+0028 LEFT PARENTHESIS (().
>
> Is this the desired behavior? It doesn't seem so, as we always consume the
> U+0028 LEFT PARENTHESIS (() code point if it is seen-- as described in two
> other places of "Consume an ident-like token."
>
> In conclusion, I believe the "reconsume the current input code point"
> portion can safely be removed.

There is a mistake there, but not the one you noticed. ^_^

The reconsume line there is intentional - if there's any whitespace
between the ( and ", I want to eventually emit a whitespace token.
Since the algo consumes all of that, though, I have to reconsume so
that the next call to consumeAToken correctly sees a whitespace
codepoint.

The bug is that if there's no whitespace, then I end up reconsuming
the ( code point, which I don't want to do.

Good catch, and fixed.

~TJ

Ezequiel Rodriguez | 25 Jul 13:35 2014
Picon

[css-syntax] Possible error in 4.3.4: Consume an ident-like token.


In the third paragraph, it states:

    ... If the next input token is U+0022 QUOTATION MARK (") or U+0027 APOSTROPHE ('),
    reconsume the current input code point, then create a <function-token> with its value set to the returned string and return it.

At the point in time the above statement is executed, the current input code point is U+0028 LEFT PARENTHESIS ((). If we reconsume the current input code point, as instructed, the next token in the stream would then be a <delim-token> with the value of U+0028 LEFT PARENTHESIS (().

Is this the desired behavior? It doesn't seem so, as we always consume the U+0028 LEFT PARENTHESIS (() code point if it is seen-- as described in two other places of "Consume an ident-like token."

In conclusion, I believe the "reconsume the current input code point" portion can safely be removed.

Thanks,
Ezequiel Rodriguez
Claude Petit | 25 Jul 04:58 2014
Picon

Additional Overflow values

Hi,

 

I’m a new member of the mailing list, and I have a request, new or not.

 

Look at the following site : http://www.brunildo.org/test/Overflowxy2.html

 

I’d like to get every combinations possible, while keeping compatibility. So, I suggest the following values for “overflow-x” and “overflow-y” : “force-visible”, “force-hidden. “force-scroll”, ... I think I don’t need to explain.

 

 

Claude Petit

 

fantasai | 25 Jul 11:08 2014
Picon

Re: [css3-background] PFWG input on focus ring

On 07/24/2014 11:43 PM, Antony Kennedy wrote:
>
> Sure, but perhaps I am misunderstanding here.
>
> If I am writing my own user stylesheet, and I want to say "do not allow
> the author to change the focus outline from the browser defaults" is
> there a way I can do that without duplicating the browser defaults in
> my user stylesheet?

No, there is not. Just as there is no way to do that for font selection
or other defaults. They are expected to be represented as style rules
in the user level of the cascade, whether in CSS syntax or hard-coded
into the engine.

~fantasai


Gmane