On Tue, Jul 16, 2013 at 6:41 PM, Ian Hickson i...@hixie.ch wrote:
This thread was gigantic and involved many proposals. I've only included
the last one below, since it seemed to take into account the most of the
feedback mentioned on the thread; I haven't responded to all the
intermediate
Browsers seem to be rather consistent in applying the background
properties of the body element, if set, to the entire viewport, even if
e.g. the height of the body is explicitly set to a small value. Example:
!doctype html
title/title
style
body { background: green; height: 2em; }
/style
On Tue, Jul 23, 2013 at 10:37 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
Is this described somewhere in HTML or CSS specifications or drafts? I think
it should be, since it is what browsers do (tested on Firefox, Chrome, IE),
and even though it sounds absurd, I’m afraid pages may rely on
On Mon, 31 Dec 2012, Pierre Dubois wrote:
On Fri Dec 14 2012, Ian Hickson wrote:
I don't think this works for all tables. For example, the first
example in the spec in the th element's section does not get handled
correctly by your algorithm -- it treats the ID column as important,
On Mon, Jul 22, 2013 at 6:58 PM, Matt Falkenhagen fal...@chromium.org wrote:
When an element goes fullscreen, should the browser try to retain the
layout of the underlying document, e.g., by creating a placeholder for
the element?
It's not entirely clear to me what you mean by placeholder.
2013-07-23 20:44, Anne van Kesteren wrote:
On Tue, Jul 23, 2013 at 10:37 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
Is this described somewhere in HTML or CSS specifications or drafts? I think
it should be, since it is what browsers do (tested on Firefox, Chrome, IE),
and even though it
On Tue, Jul 23, 2013 at 11:19 AM, Matt Falkenhagen fal...@chromium.org wrote:
By placeholder, I mean a dummy renderer with the same dimensions as the
element before it went full screen, added in its place when it goes
fullscreen to prevent the page from reflowing. There are probably other
ways
On Thu, 10 Jan 2013, Mike West wrote:
In WebKit, loading 'iframe sandbox=allow-scripts
src=frame.html/iframe' with a framed document containing
'scriptalert(window.location.origin);/script' alerts the actual
origin of the document, which wasn't what I expected. I'm not sure
what's
On Wed, 6 Mar 2013, Anne van Kesteren wrote:
It seems we have a bunch of different policies for setting the Origin
header :-(
XMLHttpRequest always sets it to the given value.
HTML's fetch only sets it to a non-null value if a from parameter is
passed.
I originally wanted it to always
On Fri, 12 Apr 2013, Ian Melven wrote:
Freddy Braun recently noticed that he could do the following in Firefox
:
iframe id='foo' sandbox='allow-same-origin' src='inner.html'
(note no allow-scripts)
and then in the document containing the iframe:
var iframe =
On Mon, 22 Jul 2013, Matt Falkenhagen wrote:
When an element goes fullscreen, should the browser try to retain the
layout of the underlying document, e.g., by creating a placeholder for
the element?
With the top layer, it's possible to style the fullscreened element and
::backdrop such
On Mon, 22 Jul 2013, Dirk Schulze wrote:
scale(0) is invalid, and should throw an exception.
I don't think that we want to throw an exception on scale(0). No browser
does that today. WebKit did it in some places in the past but removed
the exceptions.
WebIDL says it should throw a
On Tue, 23 Jul 2013, Jukka K. Korpela wrote:
2013-07-23 20:44, Anne van Kesteren wrote:
On Tue, Jul 23, 2013 at 10:37 AM, Jukka K. Korpela
jkorp...@cs.tut.fi wrote:
Is this described somewhere in HTML or CSS specifications or drafts?
I think it should be, since it is what browsers do
On Mon, 31 Dec 2012, Jonas Sicking wrote:
On Fri, Dec 28, 2012 at 11:07 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 28 Dec 2012, Jonas Sicking wrote:
I don't think it's a good solution to leave it undefined if
all/none/some of the UA menuitems are displayed by default. While it
on an
All,
we've noticed that if you draw lines in canvas or SVG, they always end up
blurry.
For instance see this fiddle: http://jsfiddle.net/V92Gn/128/
This happens because you offset 1 pixel and then draw a half pixel stroke
on each side. Since it covers only half the pixel, the color gets mapped
Hi Rik,
Just affirming what you've said in SVG:
http://cs.sru.edu/~ddailey/svg/edgeblurs.svg
The middle rects are crisp, having been merely translated leftward and
downward by half a pixel. Zooming in from the browser rectifies the problem
(as expected) after a single tick.
I remember folks
(2013/07/24 8:19), Rik Cabanier wrote:
we've noticed that if you draw lines in canvas or SVG, they always end up
blurry.
For instance see this fiddle: http://jsfiddle.net/V92Gn/128/
As discussed with Rik privately, SVG has shape-rendering: crispEdges for
this.[1]
[1]
On Wed, 24 Jul 2013 01:18:35 +0100, David Dailey
ddai...@zoominternet.net wrote:
Just affirming what you've said in SVG:
http://cs.sru.edu/~ddailey/svg/edgeblurs.svg
The middle rects are crisp, having been merely translated leftward and
downward by half a pixel. Zooming in from the browser
yeah, at first blush that seemed what was needed.
However, this simply turns off antialiasing completely so regular artwork
looks terrible.
On Tue, Jul 23, 2013 at 5:31 PM, Brian Birtles bbirt...@mozilla.com wrote:
(2013/07/24 8:19), Rik Cabanier wrote:
we've noticed that if you draw lines in
(2013/07/24 10:07), Rik Cabanier wrote:
yeah, at first blush that seemed what was needed.
However, this simply turns off antialiasing completely so regular
artwork looks terrible.
That's a quality of implementation issue. The description of the
property value says,
Indicates that the user
On Tue, Jul 23, 2013 at 5:34 PM, Kornel Lesiński kor...@geekhood.netwrote:
On Wed, 24 Jul 2013 01:18:35 +0100, David Dailey ddai...@zoominternet.net
wrote:
Just affirming what you've said in SVG:
http://cs.sru.edu/~ddailey/**svg/edgeblurs.svghttp://cs.sru.edu/~ddailey/svg/edgeblurs.svg
I guess there's too many mights in there :-)
I want to adjust line positions and line widths to align edges with device
pixels but not the user agent might turn off anti-aliasing for all lines
and curves
On Tue, Jul 23, 2013 at 6:11 PM, Brian Birtles bbirt...@mozilla.com wrote:
(2013/07/24
Good memory!
I'll dig up that conversation to see what the conclusion was.
On Tue, Jul 23, 2013 at 5:18 PM, David Dailey ddai...@zoominternet.netwrote:
Hi Rik,
Just affirming what you've said in SVG:
http://cs.sru.edu/~ddailey/svg/edgeblurs.svg
The middle rects are crisp, having been
(The below is about Canvas only; I'm not very familiar with SVG. I think
they should be two separate discussions.)
On Tue, Jul 23, 2013 at 6:19 PM, Rik Cabanier caban...@gmail.com wrote:
we've noticed that if you draw lines in canvas or SVG, they always end up
blurry.
For instance see this
Seeing what Kornel wrote about a solution to the problem for canvas, makes
persuasive support, to me, for Glenn Maynard's argument that [concerning SVG
and canvas]
I think they should be two separate discussions.
One of the intentions (at least historically) of SVG is to allow declarative
On Tue, Jul 23, 2013 at 6:20 PM, Glenn Maynard gl...@zewt.org wrote:
(The below is about Canvas only; I'm not very familiar with SVG. I think
they should be two separate discussions.)
Agreed. Sorry to confuse the issue.
On Tue, Jul 23, 2013 at 6:19 PM, Rik Cabanier caban...@gmail.com
26 matches
Mail list logo
