On Wed, 9 Oct 2013, Rik Cabanier wrote:
> > >
> > > Yep, this is where assumptions went wrong. Dashes are calculated per
> > > subpath, not per 'line'/whole path.
> >
> > On what basis are you asserting this?
>
> see this fiddle: http://jsfiddle.net/6eGxU/25/
This demonstrates pretty well what i
On Wed, Oct 9, 2013 at 9:52 PM, Ian Hickson wrote:
>
> On Fri, 27 Sep 2013, Rik Cabanier wrote:
> > On Fri, Sep 27, 2013 at 3:35 PM, Ian Hickson wrote:
> > >
> > > The idea here is that this line:
> > >
> > > --
> > >
> > > ...would result in this dash (assuming equ
On Fri, 27 Sep 2013, Rik Cabanier wrote:
> On Fri, Sep 27, 2013 at 3:35 PM, Ian Hickson wrote:
> >
> > The idea here is that this line:
> >
> > --
> >
> > ...would result in this dash (assuming equally spaced on-off):
> >
> > --- --- --- --- ---
> >
> > ...
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).
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 t
On Wed, Oct 9, 2013 at 7:02 PM, Boris Zbarsky 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
>> querySele
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
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
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 behin
On Fri, 13 Sep 2013, Ryosuke Niwa wrote:
> On Sep 13, 2013, at 1:53 AM, Anne van Kesteren 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 text/htm
On Wed, Oct 9, 2013 at 1:29 PM, Erik Dahlstrom wrote:
> On Wed, 09 Oct 2013 10:53:29 +0200, Philip Jägenstedt
> 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 attrib
On Wed, 09 Oct 2013 10:53:29 +0200, Philip Jägenstedt
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 the content attrib
On Wed, Oct 9, 2013 at 12:02 AM, Ian Hickson 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 Element i
13 matches
Mail list logo
