Dave Crossland | 1 May 01:05 2008

Re: WebFonts ready for use


2008/4/30 Patrick Garies <pgaries <at> fastmail.us>:
>
> Actually, I can think of cases where this might be useful outside of fonts,
> so maybe HTTP headers for use with any resource might be better.

That we do not mandate the way UAs can cache other kinds of files does
not suggest that because some people want to mandate the way UAs can
cache fonts, we should enable mandating caching for all kinds of
files. Instead, it suggests to me that we should reject the idea of
mandating the way UAs can cache fonts - and leave it up to UA
developers.

--

-- 
Regards,
Dave

Alan Gresley | 1 May 01:12 2008

Re: [CSS21] Why are browser default style values different from Appendix D


Saloni Mira Rai wrote:
> Hello,
> 
> The attached CSV file contains the table with default styles by browser is attached.
> 
> Thanks,
> Saloni

Hi Saloli

Thank you. Some work you have done there but I find CVS hard to follow 
so have used a trick I developed 6 years ago.

http://css-class.com/test/css/defaults/UA-style-sheet-defaults.htm

I do believe that the default margins and padding should be included for 
LI and paddings for UL and OL for starters.

Does IE7 show the same defaults as IE8 when hasLayout doesn't come into 
play. I say this since hasLayout parent containers cause default margins 
of child elements to disappear [1].

[1] http://css-class.com/test/css/box/margins/iehaslayoutmargins.htm

Alan

Patrick Garies | 1 May 01:22 2008
Picon

Re: WebFonts ready for use


Patrick Garies wrote:
>  Actually, I can think of cases where this might be useful outside of
>  fonts, so maybe HTTP headers for use with any resource might be
>  better.

After further consideration, I withdraw the HTTP header comment since I 
don’t see how it would work; other file formats such as image formats 
aren’t referenced by name.

— Patrick Garies

David Woolley | 1 May 01:27 2008
Picon

Re: WebFonts ready for use


Patrick Garies wrote:
> 
> This could be dealt with by adding a shareability flag and/or domain 
> white‐listing mechanism to CSS3 Web Fonts that could prevent a Web font 
> from being shared indirectly.

That's what EOT fonts already do, and it is that model that people are 
rejecting in this thread.  Actually, the sharability information (people 
have referred to this as machine readable licences) doesn't even need 
EOT.  EOT basically is a domain whitelisting wrapper.

Basically, you are proposing to keep the status quo ante.

--

-- 
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

David Woolley | 1 May 01:33 2008
Picon

Re: WebFonts ready for use


Dave Crossland wrote:
> 2008/4/30 Maciej Stachowiak <mjs <at> apple.com>:
>> it would make it difficult for authors to serve a font only licensed for
>> embedding in documents they produce, since the UA may use it for other
>> documents without any deliberate action on the part of either the site or
>> the user.
> 
> I think it is a mistake to use the term "embedding" in connection with
> web-fonts, because it is misleading about how HTTP works; "linking" is
> a much more accurate term.

Embedding is the concept that font vendors use in their licencing.  I 
would suggest it is reasonably safe to assume that any vendor that 
licenced for embedding wouldn't consider deep linking from another site 
to be acceptable.

What the domain whitelisting in EOT is trying to do is to produce 
semantics closer to embedding, when the medium actually physically uses 
linking.

(Interestingly of course images in HTML are logically links, but 
designers rely on their behaving, visually, as though they were 
embedded, even if that creates copyright loopholes.)
> 

--

-- 
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
(Continue reading)

fantasai | 1 May 06:54 2008
Picon

Re: Suggestion for CSS3 selectors (fwd)


Brian J. Fink wrote:
> Well whether they decide to use < and ^ combinator notation or
> :subject, :matches, and :has, I hope they reinsert SOME syntax we can
> use BEFORE the spec gets promoted to candidate recommendation!

Oh, it won't get added to the current Selectors module.
This one is too close to REC, we aren't adding any features
at this point. It'll be a candidate for the next level,
Selectors Level 4 or whatever.

~fantasai

Andrew Fedoniouk | 1 May 08:21 2008

Re: Suggestion for CSS3 selectors (fwd)


fantasai wrote:
> 
> Brian J. Fink wrote:
>> Well whether they decide to use < and ^ combinator notation or
>> :subject, :matches, and :has, I hope they reinsert SOME syntax we can
>> use BEFORE the spec gets promoted to candidate recommendation!
> 
> Oh, it won't get added to the current Selectors module.
> This one is too close to REC, we aren't adding any features
> at this point. It'll be a candidate for the next level,
> Selectors Level 4 or whatever.
> 
> ~fantasai
> 

People, are you serious about all this?

What CPU would you use to process this:

:root < a:hover { color:sisyphean; font:boulder; }

?

This simply means recalculation of styles and layout of all DOM elements 
on simple a:hover. So is my question above.

Complexity of style resolution for *single* element using
containment selector is O(n), where n is a number of DOM elements in the 
whole tree. So resolving the whole DOM against single containment rule 
(Continue reading)

Dave Crossland | 1 May 11:27 2008

Re: WebFonts ready for use


2008/5/1 David Woolley <forums <at> david-woolley.me.uk>:
> Dave Crossland wrote:
>> I think it is a mistake to use the term "embedding" in connection with
>> web-fonts, because it is misleading about how HTTP works; "linking" is
>> a much more accurate term.
>
> Embedding is the concept that font vendors use in their licencing.  I would
> suggest it is reasonably safe to assume that any vendor that licenced for
> embedding wouldn't consider deep linking from another site to be acceptable.

Right; therefore using "embedding" in the context of web-fonts is misleading.

> What the domain whitelisting in EOT is trying to do is to produce semantics
> closer to embedding, when the medium actually physically uses linking.

This seems to me a reason for rejecting EOT.

> (Interestingly of course images in HTML are logically links, but designers
> rely on their behaving, visually, as though they were embedded,

In what sense do web publishers rely on their behaving as though they
were embedded? The results of a search like
http://www.google.com/search?q=image+hosting is evidence that many
publishers rely on cross-site image linking.

> even if that creates copyright loopholes.)

Technology isn't law.

(Continue reading)

Dave Crossland | 1 May 11:33 2008

Re: WebFonts ready for use

2008/5/1 David Woolley <forums <at> david-woolley.me.uk>:
>
> Patrick Garies wrote:
>>
>> This could be dealt with by adding a shareability flag and/or domain
>> white‐listing mechanism to CSS3 Web Fonts that could prevent a Web font from
>> being shared indirectly.
>
> That's what EOT fonts already do, and it is that model that people are
> rejecting in this thread.  A

>  EOT basically is a domain whitelisting wrapper.

I think it is dramatically more than that; because of the encryption,
EOT is an "effective technological measure" under any applicable law
fulfilling obligations under article 11 of the WIPO copyright treaty
adopted on 20 December 1996, or similar laws prohibiting or
restricting circumvention of such measures. This prohibits its
implementation in free software web browsers, and therefore must be
rejected.

Webservers already have a mechanism for domain whitelisting of images
to deter deep-linking them - by checking that the HTTP Referrer
headers match the domain names they serve pages from. This can
obviously work just the same way for domain whitelisting of fonts.

--

-- 
Regards,
Dave
(Continue reading)

Keryx Web | 1 May 11:41 2008
Picon

Re: [CSS21] Slash A (WAS: Why are browser default style values different from Appendix D)


Alan Gresley wrote:
  > http://css-class.com/test/css/defaults/UA-style-sheet-defaults.htm

And I saw: http://www.w3.org/TR/CSS21/sample.html

Especially br:before.

Excuse an idiot (someone who lacks sufficient knowledge) for asking.

But I must be missing something, but is not \a the same as "bell"?

Lars Gunther


Gmane