On Wed, Oct 9, 2013 at 12:02 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 8 Oct 2013, Simon Pieters wrote:
I think it would be bad to have an IDL attribute without a working
content attribute for a given element. That's just confusing.
Yeah, that's the main reason I wouldn't put this on
On Wed, 09 Oct 2013 10:53:29 +0200, Philip Jägenstedt phil...@opera.com
wrote:
...
OK, I hadn't considered that moving this to Element would imply the
content attributes being reflected for all namespaces. Even though
Blink has the IDL attributes on Element, it looks like the reflection
with
On Wed, Oct 9, 2013 at 1:29 PM, Erik Dahlstrom e...@opera.com wrote:
On Wed, 09 Oct 2013 10:53:29 +0200, Philip Jägenstedt phil...@opera.com
wrote:
...
OK, I hadn't considered that moving this to Element would imply the
content attributes being reflected for all namespaces. Even though
On Fri, 13 Sep 2013, Ryosuke Niwa wrote:
On Sep 13, 2013, at 1:53 AM, Anne van Kesteren ann...@annevk.nl wrote:
It's not entirely clear to me what the suggestion from Ryosuke is. Is
it to keep getters on HTMLDocument only and expose HTMLDocument only
in browsing contexts created from
OK, so I gave this some thought and I and Olli managed to convince each
other that finding a solution to the problem of dispatching a generic
onclose event is impossible since there is no deterministic point in time
before a worker is GCed when we know that it will be GCed soon.
So with that
Right now the spec says[1] Whenever a Document object is discarded, it
must be removed from the list of the worker's Documents of each worker
whose list contains that Document.. If I'm reading this correctly, this
implies that the worker object should be alive by the time that the
document gets
On 6/28/13 10:01 PM, Boris Zbarsky wrote:
On 6/28/13 5:06 PM, Tab Atkins Jr. wrote:
getElementById(foo) is just querySelector(#foo)
This is actually false. For example, getElementById(foo:bar) is just
querySelector(#foo\\:bar), which is ... nonobvious.
And today someone asked me how to do
On Wed, Oct 9, 2013 at 7:02 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/28/13 10:01 PM, Boris Zbarsky wrote:
On 6/28/13 5:06 PM, Tab Atkins Jr. wrote:
getElementById(foo) is just querySelector(#foo)
This is actually false. For example, getElementById(foo:bar) is just
Eventually ES6 template strings [1] will make this awesome, as you'll do
querySelector(css`\n`)
or
querySelector(css`[data-some-id=${myId}]`)
or even
qs`[data-some-id=${myId}]`
But someone has to write these functions (css and/or qs) and there's no point
in creating standard versions until
On 10/9/13 8:40 PM, Glenn Maynard wrote:
But it's already been suggested--by you--that we need a function to
CSS-escape a string
Sure. This was just an additional data point as to why: CSS escaping a
newline is not very obvious.
which seems to solve the that problem trivially (for users).
On Fri, 27 Sep 2013, Rik Cabanier wrote:
On Fri, Sep 27, 2013 at 3:35 PM, Ian Hickson i...@hixie.ch wrote:
The idea here is that this line:
--
...would result in this dash (assuming equally spaced on-off):
--- --- --- --- ---
...while
On Wed, Oct 9, 2013 at 9:52 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 27 Sep 2013, Rik Cabanier wrote:
On Fri, Sep 27, 2013 at 3:35 PM, Ian Hickson i...@hixie.ch wrote:
The idea here is that this line:
--
...would result in this dash
12 matches
Mail list logo
