On Sat, Jun 8, 2013 at 11:08 AM, Ian Hickson i...@hixie.ch wrote:
If browsers align on the above text the HTML spec indeed would no longer
need to worry about this, since there'd no longer be any cross-origin
fonts. Has this occurred?
(Personally I don't really see why we'd limit this to
On Thu, 2 May 2013, Rik Cabanier wrote:
The canvas 2d spec currently states that a font has to be local in order
for measureText to work: [1][2]
If doing these measurements requires using a font that has an origin
that is not the same as that of the Document object that owns the canvas
On Fri, Jun 7, 2013 at 4:08 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 2 May 2013, Rik Cabanier wrote:
The canvas 2d spec currently states that a font has to be local in order
for measureText to work: [1][2]
If doing these measurements requires using a font that has an origin
that
On 6/7/13 7:08 PM, Ian Hickson wrote:
If browsers align on the above text the HTML spec indeed would no longer
need to worry about this, since there'd no longer be any cross-origin
fonts. Has this occurred?
No, though they have all in principle agreed that they plan to when they
didn't object
On Sat, May 4, 2013 at 1:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, May 3, 2013 at 6:25 PM, Rik Cabanier caban...@gmail.com wrote:
On Fri, May 3, 2013 at 2:23 AM, Anne van Kesteren ann...@annevk.nl
wrote:
1. That assumes tainted cross-origin as a fetching mode.
On Fri, May 3, 2013 at 6:25 PM, Rik Cabanier caban...@gmail.com wrote:
On Fri, May 3, 2013 at 2:23 AM, Anne van Kesteren ann...@annevk.nl wrote:
1. That assumes tainted cross-origin as a fetching mode.
http://fetch.spec.whatwg.org/#concept-request-mode Whereas you assume
it uses CORS.
What
On Thu, May 2, 2013 at 10:49 PM, Rik Cabanier caban...@gmail.com wrote:
Reading the Origin spec [1]:
For fonts:
The origin of a downloadable Web font is an alias to the origin of the
absolute URL used to obtain the font (after any redirects). [CSSFONTS]
The origin of a locally installed
On Fri, May 3, 2013 at 3:07 PM, Boris Zbarsky bzbar...@mit.edu wrote:
The text at
http://dev.w3.org/csswg/css-fonts/#default-same-origin-restriction and
http://dev.w3.org/csswg/css-fonts/#allowing-cross-origin-font-loading
predates your introduction of the mode values, but clearly corresponds
On Fri, May 3, 2013 at 2:23 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, May 2, 2013 at 10:49 PM, Rik Cabanier caban...@gmail.com wrote:
Reading the Origin spec [1]:
For fonts:
The origin of a downloadable Web font is an alias to the origin of the
absolute URL used to obtain
The canvas 2d spec currently states that a font has to be local in order
for measureText to work: [1][2]
If doing these measurements requires using a font that has an origin that
is not the same as that of the Document object that owns the canvas element
(even if using a font means just checking
On Thu, May 2, 2013 at 10:36 PM, Rik Cabanier caban...@gmail.com wrote:
Does anyone know what this is? It seems to us, that if the font is
available to CSS (depending on if the browser supports CORS for fonts), it
should be fine to call measureText.
In that case the font's origin would be the
On Wed, 26 Sep 2012, Hugh Guiney wrote:
My use case: I have a div with overflow: hidden that contains slides
as part of a JavaScript carousel. It has to be overflow: hidden because
otherwise the unseen slides are visible/stretch the page. And because
each slide is different, the containing
This might also be useful for us here at Mozilla (and perhaps the folks
at WebKit). The reason being, if the text-size-adjust property
(currently -webkit-text-size-adjust and -moz-text-size-adjust... not
sure if other browsers implement this) becomes a spec, we then have to
deal with the case
My use case: I have a div with overflow: hidden that contains slides
as part of a JavaScript carousel. It has to be overflow: hidden
because otherwise the unseen slides are visible/stretch the page. And
because each slide is different, the containing div therefore needs
to grow/shrink in height
I'm implementing style scope for WebKit at the moment, so please allow me
to add my take to some of the issues raised (although I certainly don't
claim to be an authoritative source of insight! ^_-). Comments inline:
On Sat, Nov 19, 2011 at 10:11, Daniel Glazman
On Tue, Nov 22, 2011 at 13:12, Roland Steiner rolandstei...@chromium.orgwrote:
I'm implementing style scope for WebKit at the moment, so please allow
me to add my take to some of the issues raised (although I certainly don't
claim to be an authoritative source of insight! ^_-). Comments
On Fri, 18 Nov 2011, Roland Steiner wrote:
When thinking about implementation details of @font-face rules in style
scoped, I started to wonder whether a (nested) scoped style-sheet
should be able to create a new - or even override an existing - a
font-family declared in an outside scope.
Le 18/11/11 23:40, Ian Hickson a écrit :
I'm happy to add clarifying text or an example to the spec if that would
help.
[cc to www-style, reply-to to www-style ]
Wow, wow, wow. Slowly please.
I think you should discuss that in www-style before any addition to
html. The complete mechanism
Hi all,
When thinking about implementation details of @font-face rules in style
scoped, I started to wonder whether a (nested) scoped style-sheet should
be able to create a new - or even override an existing - a font-family
declared in an outside scope. To give examples:
Defining a font-family
On Sat, 03 Apr 2010 17:23:39 +0300, Greg Brown gkbr...@mac.com wrote:
OK, that makes sense. Thanks for the info.
However, a extra readonly attribute float height to the TextMetrics
interface should be fairly trivial to implement for browser vendors and
would greatly help web developers
OK, that makes sense. Thanks for the info.
On Apr 2, 2010, at 5:39 PM, Ian Hickson wrote:
On Fri, 2 Apr 2010, Greg Brown wrote:
In reviewing the current draft API for the canvas element
(http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html),
I noticed
Hi all,
In reviewing the current draft API for the canvas element
(http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html),
I noticed that there is no support for obtaining font metrics such as ascent,
descent, leading, and bounding box. It seems like the most
On Fri, 2 Apr 2010, Greg Brown wrote:
In reviewing the current draft API for the canvas element
(http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html),
I noticed that there is no support for obtaining font metrics such as
ascent, descent, leading, and
(I'm replying only to the more salient e-mails in this thread, as the
others mostly just repeated stuff. I'm also only cc'ing whatwg, since that
seems to be where most of the contributors on this thread were subscribed
to -- please don't cross-post, as it results in threads that appears to be
Adrian Sutton wrote:
The issue isn't that it's hard to fix the WYSIWYG editor, the issue is that
it's hard to fix all the rest of the systems the client wants and the fact
that clients tend to want a font menu in their editor otherwise they
completely eliminate it from consideration without
Hello,
I have been following the discussion on the use of font tags for
WYSIWYG editors. Just thought I'd post some thoughts as a CMS vendor,
hope they are not out of place. Hope this isn't a double post, my
first attempt was moderated.
On 03/05/2007, at 4:48 AM, Adrian Sutton wrote:
On 8/5/07 8:13 PM, Adrian Lynch [EMAIL PROTECTED] wrote:
I am sure there are just as many ingrained CMS's producing font
tags in their output without using a WYSIWYG editor - they will need
to be modified to meet specification, but WYSIWYG editors get a
reprieve? Surely making a WYSIWYG editor
Sander Tekelenburg wrote:
And while we add all that presentational HTML to the spec, some enterprising
hacker builds a HTML-PDF converter that has CSS support -- we'll have a spec
allowing things we didn't really want to allow and for which there's not even
a use case anymore.
Well, PrinceXML
Adrian Sutton wrote:
That said, by default our editor outputs the span tag version because we
like to follow standards and I recommend using our styles menu to apply CSS
classes and appropriate structural markup (headings etc). We did however
have to go back and add an option to output font
On 2/5/07 4:59 PM, Benjamin Hawkes-Lewis [EMAIL PROTECTED]
wrote:
Adrian Sutton wrote:
That said, by default our editor outputs the span tag version because we
like to follow standards and I recommend using our styles menu to apply CSS
classes and appropriate structural markup (headings
At 11:01 +1000 UTC, on 2007-05-02, Adrian Sutton wrote:
On 2/5/07 1:28 AM, Sander Tekelenburg [EMAIL PROTECTED] wrote:
[...]
can you explain exactly how span is much more difficult to work
with, and for whom?
Quite a number of the cheap HTML to PDF conversion processes don't support
CSS.
At 12:48 +1000 UTC, on 2007-05-01, Adrian Sutton wrote:
[...]
The only debate about what a WYSIWYG editor is on the web is between a very
strict interpretation (it must look precisely like what you get) and the
What You See Is What You Mean editors.
That's one, yes. But also plenty of people
The current phrasing doesn't restrict this to span. It allows WYSIWYG
editors to produce pfont size=7blah/font/p where h1blah/h1 is
appropriate.
If I understand correctly, even that wouldn't be correct, because the only
attribute specifically allowed on font is the style attribute. I
Jon Barnett writes:
If font is allowed, then font size could be allowed, because a
server-side script could more easily find font size=7 and replace it
with h1.
Why would that be a correct thing to do? If somebody has made text
large for emphasis or other effect, then labelling it as a
At 12:47 -0500 UTC, on 2007-05-01, Jon Barnett wrote:
[...]
the only attribute specifically allowed on font is the style attribute.
Whoops. Somehow I overlooked that. My bad. But given that, I *really* don't
see the point of font anymore.
I've searched the archive at
On 2/5/07 1:28 AM, Sander Tekelenburg [EMAIL PROTECTED] wrote:
That's one, yes. But also plenty of people don't even distinguish between the
editor embedded within a publishing tool, and the publishing tool as a whole.
So as it is phrased now in WebApps 1.0, I wouldn't be surprised if it will
Embedded and inline editors would include the textarea tag, which is
clearly
not WYSIWYG for HTML (but is for plain text) so both are poor terms.
Embedded, inline editors would include contenteditable areas and documents
with designMode on, like the box I'm typing in right now in Gmail.
Quite
At 15:01 -0700 UTC, on 2007-04-30, Maciej Stachowiak wrote:
[...]
Note that although the WHATWG spec requires UAs to
support FONT, it makes it non-conformant for documents except those
created by a WYSIWYG editor. And even that aspect is in dispute.
Yeah, I meant to ask about
On 1/5/07 9:52 AM, Sander Tekelenburg [EMAIL PROTECTED] wrote:
At 15:01 -0700 UTC, on 2007-04-30, Maciej Stachowiak wrote:
What's even more weird is the idea to consider content non-/conforming
depending on how it was authored. I can't believe the implications of that
were given serious
http://whatwg.org/specs/web-apps/current-work/#the-font
The definition of font and style='' seems like a compromise that
isn't good for either side of the style='' debate. Can it be
reconsidered, please?
Using font style='' as a block container is less backwards
compatible than div
On Fri, 12 Jan 2007 10:03:34 +0100, Henri Sivonen [EMAIL PROTECTED] wrote:
Furthermore, I suggest allowing style='' on all elements, because only
allowing it on div and span would only move WYSIWYG output even more
to the direction of Karl Dubost's caricature of HTML 6.0.
I second that.
41 matches
Mail list logo
