Re: [CSS3-UI] text-overflow:ellipsis (freshly rewritten/expanded and incorporated into editor's draft)

On Sun, Jan 23, 2011 at 19:04, Robert O'Callahan <robert <at> ocallahan.org> wrote:
> On Mon, Jan 24, 2011 at 8:02 AM, Tantek Çelik <tantek <at> cs.stanford.edu>
> wrote:
>>
>> On Sun, Jan 23, 2011 at 00:56, Robert O'Callahan <robert <at> ocallahan.org>
>> wrote:
>> > On Sat, Jan 22, 2011 at 7:53 PM, Tantek Çelik <tantek <at> cs.stanford.edu>
>> > wrote:
>> >>
>> >> I've applied the filter of only documenting what appears to be
>> >> interoperably implemented,
>> >
>> > Unfortunately, only the simplest situations are handled interoperably
>> > among
>> > IE, Webkit and Opera, so documenting the interoperable stuff leaves most
>> > behavior undefined .
>>
>>
>> If that's so, then web authors/developers are unlikely to be depending
>> on things other than "the simplest situations".
>>
>> That will do for CSS3-UI.  Anything that is currently not
>> interoperable among the three implementations I will leave explicitly
>> undefined / up to the implementation in CSS3-UI.
>
> Personally I would rather not have the feature appear in a spec, than have
> it appear with such a large volume of undefined behavior. If it was a
> genuinely new feature I would object most strenuously.

I tend to agree. Any genuinely new feature should be specified with

[css3-text] Hyphenation Resources

The current CSS3 Text spec defines a 'hyphenation-resource'  <at> -rule:

  http://dev.w3.org/csswg/css3-text/#hyphenation-resource

This was based on a similar property defined in CSS3 GCPM:

  http://dev.w3.org/csswg/css3-gcpm/#the-hyphenate-resource-property

However, neither of these reference or define a syntax for the
hyphenation resource. Effectively, these are UA-specific
resources when defined this way.  As such, I don't see any reason
for supporting either the  <at> -rule or the property in the current
form; they're both effectively vendor-specific properties with
*no* interoperability between user agents.  I think the format
should be defined/referenced explicitly or it should be removed
from the spec and left to a vendor-specific property.

For example, Antenna House uses this syntax:

  http://www.antennahouse.com/product/ahf50/hyp_dictionary.htm

Would this be a suitable format to require?  Or is there another
publicly available format that would also suffice?  Maybe
something from TeX would work?  What does Prince use?

I think one argument will be that CSS doesn't specify formats for
other types of resources such as images.  But in the case of
images there were already well-supported image types, so it
wasn't really necessary to specify these to achieve some form of
interoperability.  The same is not true for hyphenation

Re: [css3-text] Hyphenation Resources

Looking at this a tiny bit more, it appears that the AH format is
actually based on FOP:

  http://xmlgraphics.apache.org/fop/1.0/hyphenation.html

I'm curious if folks working on XSL/FOP feel that the formats and
algorithms used for automated hyphenation have been sufficiently
flushed out enough to allow for a common format?  Or would it be
better to allow user agents room to innovate and then define
something later?

John Daggett

cc'ing Liam Quinn

----- Original Message -----
From: "John Daggett" <jdaggett <at> mozilla.com>
To: "www-style list" <www-style <at> w3.org>
Sent: Tuesday, February 1, 2011 4:15:08 PM
Subject: [css3-text] Hyphenation Resources

The current CSS3 Text spec defines a 'hyphenation-resource'  <at> -rule:

  http://dev.w3.org/csswg/css3-text/#hyphenation-resource

This was based on a similar property defined in CSS3 GCPM:

  http://dev.w3.org/csswg/css3-gcpm/#the-hyphenate-resource-property

Re: [CSS3-UI] text-overflow:ellipsis (freshly rewritten/expanded and incorporated into editor's draft)

Re: [css3-text] Hyphenation Resources

Also sprach John Daggett:

 > The current CSS3 Text spec defines a 'hyphenation-resource'  <at> -rule:
 > 
 >   http://dev.w3.org/csswg/css3-text/#hyphenation-resource
 > 
 > This was based on a similar property defined in CSS3 GCPM:
 > 
 >   http://dev.w3.org/csswg/css3-gcpm/#the-hyphenate-resource-property
 > 
 > However, neither of these reference or define a syntax for the
 > hyphenation resource.

As such, the 'hyphenate-resource property is similar to the
'cursor' property:

  http://www.w3.org/TR/css3-ui/#cursor

 > Effectively, these are UA-specific resources when defined this way.

Not quite. Both Prince and Antenna House supports the TeX format, it
seems. Having a standardized way of referencing the hyphenation
resources therefore make sense. I believe the TeX format is also used
in many other products.

Even when differnet UAs support different formats, the comma-separated
list will handle the situation:

  body { hyphenate-resource: url(hyph.dic), url(hyph.dac) }

The result would be interoperable between a formatter that supports
"dic" and the (more hypothetical) "dac" format.

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome <at> opera.com                  http://people.opera.com/howcome

Re: [css3-text] Hyphenation Resources

On 1 Feb 2011, at 08:34, Håkon Wium Lie wrote:

> Also sprach John Daggett:
> 
>> The current CSS3 Text spec defines a 'hyphenation-resource'  <at> -rule:
>> 
>>  http://dev.w3.org/csswg/css3-text/#hyphenation-resource
>> 
>> This was based on a similar property defined in CSS3 GCPM:
>> 
>>  http://dev.w3.org/csswg/css3-gcpm/#the-hyphenate-resource-property
>> 
>> However, neither of these reference or define a syntax for the
>> hyphenation resource.
> 
> As such, the 'hyphenate-resource property is similar to the
> 'cursor' property:
> 
>  http://www.w3.org/TR/css3-ui/#cursor

Or the src descriptor in  <at> font-face rules, for example.

> 
>> Effectively, these are UA-specific resources when defined this way.
> 
> Not quite. Both Prince and Antenna House supports the TeX format, it
> seems. Having a standardized way of referencing the hyphenation
> resources therefore make sense. I believe the TeX format is also used
> in many other products.

Hyphenation resources based on TeX's are used in a number of products, but I'm not sure quite how
"standardized" those files are. Some of the TeX files in circulation (e.g., found on CTAN or other
sources) include macros, etc, and probably can't be used exactly as-is by non-TeX processors even if they
rely on the same underlying algorithms. Referring to "the TeX format" is not an adequate way to identify a
specific, interoperable resource format.

> 
> Even when differnet UAs support different formats, the comma-separated
> list will handle the situation:
> 
>  body { hyphenate-resource: url(hyph.dic), url(hyph.dac) }
> 
> The result would be interoperable between a formatter that supports
> "dic" and the (more hypothetical) "dac" format.

This would be improved, IMO, by adding "format hints" similar to those in  <at> font-face, so that the UA can
avoid downloading resources that it won't be able to use. E.g.,

body {
  hyphenate-resource: url(hyph.dic) format "TeX", url(hyphens.dac) format "foo",
url(hyph_en_US.xml) format "FOP";
}

or maybe

 <at> hyphenate-resource {
  lang: "en-US";
  src: url(hyph.dic) format "TeX", url(hyphens.dac) format "foo", url(hyph_en_US.xml) format "FOP";
}

JK

Fw: Re: [css3-text] Hyphenation Resources

(Forwarded with permission.)

----- Forwarded message from Jeremias Maerki <dev <at> jeremias-maerki.ch> -----

From: Jeremias Maerki <dev <at> jeremias-maerki.ch>
Date: Tue, 01 Feb 2011 09:32:23 +0100
To: fop-dev <at> xmlgraphics.apache.org
Cc: Cameron McCormack <cam <at> mcc.id.au>
Subject: Re: [css3-text] Hyphenation Resources

Hi Cameron

I'm not sure if it is feasible to have/create a standardized format. I
guess it makes sense to stay as close to LaTex as possible. FOP just put
the patterns into an XML format (using Unicode). It seems to work fine
for us. Java-based CSS3 implementation could easily re-use FOP's
hyphenation module. We rarely have inquiries on the user list concerning
hyphenation.

The larger issues is the mess of licenses for the various patterns which
is why we've had to move the patterns outside to http://offo.sf.net
because we can't fulfil the Apache Foundation's license policy. Tracking
down individual authors of the original pattern files and getting
permission to put them under the ALv2 turned out to be a tedious task.
Not all authors can be contacted. So today, the users would essentially
have to check for themselves if the license restrictions are fine for
their particular use case.

There was once a discussion about looking toward OpenOffice (probably
rather LibreOffice today) for re-use of their hyphenation modules. But
that hasn't happened probably due to effort that would need to be
invested for the change. I haven't looked into that closely myself. But
it could be another option for CSS3 implementations.

That said, it would certainly be very very useful to have a good set of
widely usable hyphenation patterns that have a clear, uniform and
permissive license. The current situation is less than ideal for Apache
FOP.

HTH

On 01.02.2011 09:04:21 Cameron McCormack wrote:
> Hi fop devs.
> 
> There is discussion on www-style <at> w3.org about hypenation dictionary
> formats, and FOP was mentioned.  Does someone have the knowledge to
> comment there?
> 
> ----- Forwarded message from John Daggett <jdaggett <at> mozilla.com> -----
> 
> From: John Daggett <jdaggett <at> mozilla.com>
> Date: Mon, 31 Jan 2011 23:36:59 -0800 (PST)
> To: www-style list <www-style <at> w3.org>
> Cc: liam <at> w3.org, jfkthame <at> gmail.com
> Subject: Re: [css3-text] Hyphenation Resources
> Archived-At: <http://www.w3.org/mid/1971349164.157469.1296545819806.JavaMail.root <at> cm-mail03.mozilla.org>
> 
> Looking at this a tiny bit more, it appears that the AH format is
> actually based on FOP:
> 
>   http://xmlgraphics.apache.org/fop/1.0/hyphenation.html
> 
> I'm curious if folks working on XSL/FOP feel that the formats and
> algorithms used for automated hyphenation have been sufficiently
> flushed out enough to allow for a common format?  Or would it be
> better to allow user agents room to innovate and then define
> something later?
> 
> John Daggett
> 
> cc'ing Liam Quinn
> 
> …

----- End forwarded message -----

--

-- 
Cameron McCormack ≝ http://mcc.id.au/

Re: in-between values

On Fri, Jan 21, 2011 at 7:54 PM, Brad Kemper <brad.kemper <at> gmail.com> wrote:
> I had an idea for a special value that could be used with a variety of properties,
> for transitioning, animating, or just picking single values that are in between two
> values that don't normally have any mid-points. So for instance:

> background-clip: mid(border-box, padding-box, 0.24) /* would clip 1/4 of the way from border-box to
padding-box */
> background-clip: mid(padding-box, border-box, 0.24) /* would clip 1/4 of the way from padding-box to
border-box */

Isn't 1/4 usually 0.25? Why did you write 0.24, is there some magic going on?

> color: mid(transparent, blue, 0.7) /* equivalent to color:blue; opacity:0.7 */
> color: mid(blue, transparent, 0.7) /* equivalent to color:blue; opacity:0.3 */

It took me a couple of readings to understand this. You aren't using
mid to mean 'midpoint'...

A graphic here would have helped.

T123456789B
-------x    color: mid(transparent, blue, 0.7) /* equivalent to
color:blue; opacity:0.7 */
   x------- color: mid(blue, transparent, 0.7) /* equivalent to
color:blue; opacity:0.3 */

fwiw, the other mid that comes to mind is:
MID$(stringexpression$, start, length)

Which obviously doesn't behave the way you're using it here. I've had
a hard enough time trying to describe this to myself that i expect
people will mess this up while trying to use it. -- I really don't
like the name.

We already will have calc() and eventually css variables, do we need
another thing here? if we gave calc() the ability to operate on colors
(and other things), would that work?

> border-style: mid(dashed,solid,0.5) /* spaces between dashes are half their normal length */

What would be the result for border-style: mid(double, dashed, 0.6)

could i do border-style: mid(groove, mid(double, dashed, 0.4), 0.7) ?

Parsing background shorthand

Spec ( http://www.w3.org/TR/css3-background/#the-background ) gives few  
examples for background shorthand that do not work in neither Opera,  
Firefox or Chrome:

40% url("chess.png") / 10em gray round fixed border-box
#CCC top left url("metal.jpg") / 100% auto no-repeat

Syntax of shorthand is defined as:

<final-bg-layer> = <bg-image> || <bg-position> [ / <bg-size> ]? ||  
<repeat-style> || <attachment> || <box>{1,2} || <'background-color'>

Both of these examples have bg-position placed before bg-image and then  
only after bg-image they specify "/ bg-size". That looks wrong to me (and  
to tested browsers).

If I move bg-position to be located before "/ bg-size" then it works in  
Opera but still doesn't work in Chrome and Firefox.

Are we dealing with bad examples + incomplete implementations or I'm doing  
something wrong?

--

-- 
Rafał Chłodnicki
Core QA, Opera Software ASA

Re: Parsing background shorthand

On Tue, 01 Feb 2011 12:48:36 +0100, Rafal Chlodnicki  
<rchlodnicki <at> opera.com> wrote:

> Spec ( http://www.w3.org/TR/css3-background/#the-background ) gives few  
> examples for background shorthand that do not work in neither Opera,  
> Firefox or Chrome:
>
> 40% url("chess.png") / 10em gray round fixed border-box
> #CCC top left url("metal.jpg") / 100% auto no-repeat
>
> Syntax of shorthand is defined as:
>
> <final-bg-layer> = <bg-image> || <bg-position> [ / <bg-size> ]? ||  
> <repeat-style> || <attachment> || <box>{1,2} || <'background-color'>
>
> Both of these examples have bg-position placed before bg-image and then  
> only after bg-image they specify "/ bg-size". That looks wrong to me  
> (and to tested browsers).
>
> If I move bg-position to be located before "/ bg-size" then it works in  
> Opera but still doesn't work in Chrome and Firefox.
>
> Are we dealing with bad examples + incomplete implementations or I'm  
> doing something wrong?

Just noticed that examples are fixed in draft already:
http://dev.w3.org/csswg/css3-background/#the-background

--

-- 
Rafał Chłodnicki
Core QA, Opera Software ASA